From john.elwell@siemens-enterprise.com Tue Jan 5 01:36:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913C728C0D0 for ; Tue, 5 Jan 2010 01:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vectz3jmXjwa for ; Tue, 5 Jan 2010 01:36:13 -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 BE32B3A68B1 for ; Tue, 5 Jan 2010 01:36:09 -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-436382; Tue, 5 Jan 2010 10:36:07 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A387F1EB828D; Tue, 5 Jan 2010 10:36:07 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 10:36:07 +0100 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Tue, 5 Jan 2010 10:36:05 +0100 Thread-Topic: [martini] draft-kaplan-martini-mixing-problems: solution requirements? Thread-Index: AcqIFqukGaGtwsm6Tuij11Ea29pLhQFyo5lQ Message-ID: References: <4B394119.4040502@nostrum.com> In-Reply-To: <4B394119.4040502@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 09:36:14 -0000 Thanks to Bernard for highlighting the issues and to Adam for his initial r= esponse. My thoughts are interleaved below. =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 28 December 2009 23:37 > To: martini@ietf.org > Cc: Bernard Aboba > Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > solution requirements? >=20 > On 12/28/09 12:53 AM, Bernard Aboba wrote:=20 >=20 > Currently, these sections articulate the issues, but=20 > don't make recommendations as to which of the issues a=20 > potential solution needs to solve. Some of the issues are=20 > indicated as open in the solution proposals (e.g. open=20 > question on PAU/Wildcard syntax in=20 > draft-kaplan-martini-shaken-implicit-registrations) so this=20 > is not just a rhetorical question.=20 > =09 > Here's a list of the Issues described in Sections 4, 5 & 6.=20 > =09 > 4.1. Explicit Indication of Multiple AOR Registration > =09 >=20 >=20 > I think this is REQUIRED. [JRE] Agreed. >=20 >=20 >=20 > 4.2-4.4: Usage of P-Associated URI > a. Inclusion of PAU > b. Avoidance of SIP Response fragmentation > 1. Non-wildcard mitigation > 2. Support for Wildcard syntax > 3. Compatibility of Wildcard syntax with TEL URI > c. Defined behavior of IP-PBX on PAU mismatch > =09 >=20 >=20 > I don't think we want to rely on PAU behavior to make a=20 > multiple registration solution work. The definition in=20 > RFC3455 is pretty well constrained to an exhaustive=20 > enumeration of identities, which is not appropriate for the=20 > kind of use cases MARTINI is discussing. Even more=20 > importantly, it was meant for something rather different than=20 > MARTINI's problem space: multiple identities that=20 > semantically mean *exactly* the same *user*. Not billing=20 > entity, but actual *user*. >=20 > So, I think all the PAU issues are IRRELEVANT with regards to=20 > PAU itself. [JRE]I don't want to see a solution that relies on PAU. >=20 > However, I think we need to carefully consider the semantic=20 > issues that are implied by these sections. Things like: >=20 >=20 > * Who designates which URIs the request is attempting to=20 > register? For example, if a company has a single PBX and=20 > decides to split its users between two different PBXes (say,=20 > at different sites) -- does it need to get the SSP to=20 > reprovision the URIs associated with its implicit=20 > registrations? Or would it make more sense for the request to=20 > indicate which URIs it was attempting to register? This would=20 > allow the company to move URIs around between its own PBXes=20 > without a provisioning action at the SSP. [JRE] I don't think this is a problem we necessarily need to solve at this = stage. It would involve issues such as what if two PBXs try to register ove= rlapping sets of AORs, and what if one of the AORs in the request is one th= at the PBX is not entitled to use. Provisioning will in any case be needed = at the SSP whenever a new AOR is added to (or removed from) the total pool,= so requiring provisioning also for the case where an AOR moves PBX is not = out of the question. > =09 > =09 > * How does the UAC know which URIs have just been=20 > registered? If they don't match what it expects, how does it=20 > react? Note that this problem goes away if we allow the user=20 > to designate which URIs they're attempting to register in the=20 > request. Granted, it pushes the responsibility of verifying=20 > the URIs onto the SSP equipment, but at least it can send an=20 > error response if the requestor is not authorized to use the=20 > specified URIs. > =09 > =09 > * Response size is a real concern, since there's no way=20 > to switch from UDP to TCP at the UAS side when responses are=20 > too large for the MTU. On the other hand, the requestor can=20 > always elect to use TCP if the request is too large. This,=20 > again, points to having the requestor indicate the URIs to be=20 > used instead of the responder.=20 >=20 > Which is to say: I think the implicit model currently under=20 > discussion in the problems and implicit-registration drafts=20 > is going about the issue backwards. I believe that there are=20 > a number of reasons it makes much more sense to have an=20 > explicit model in which the PBX tells the SSP which URIs it=20 > is attempting to register, and the SSP accepts or denies the=20 > request based on authorization policy. >=20 >=20 >=20 > 5.1 Retaining Target Info > 5.2 Contact-URI handling > a. Request-URI > b. Route Header > =09 >=20 >=20 > I think retaining all the information that the PBX used to=20 > indicate itself -- the "Contact" header field in Hadriel's=20 > drafts -- is REQUIRED. Clearly, we also need the ability to=20 > tell which extension is being addressed (i.e., this is=20 > REQUIRED as well). >=20 > I'm less concerned about the mechanisms used to convey this=20 > information. Ideally, it would be as consistent with normal=20 > handling as is possible -- meaning that the Request URI is=20 > semantically the information the PBX used to indicate itself=20 > (again, the "Contact" header field in Hadriel's proposals). [JRE] It depends what you mean by "normal handling". From the PBX's point o= f view, it would be more normal for the target AOR to appear in the Request= -URI - that is where it would appear if the request had come from another s= ource, e.g., a local UA, another PBX in the enterprise network, or another = domain with which the PBX peers. >=20 > When you think about how currently-deployed multiline SIP=20 > phones handle this situation, they'll usually use the user=20 > portion of the Contact header field to keep track of which of=20 > its several identities a request is associated with. For=20 > example, a phone may register the AOR "sip:adam@example.com"=20 > with a Contact of=20 > "sip:line1@192.168.1.15" , and=20 > register "sip:some-other-id@example.net"=20 > with a Contact of=20 > "sip:line2@192.168.1.15" . That's=20 > kind of nice, because it lets the end device correlate=20 > information according to its own local scheme. [JRE] Is the use of example.com for the first line and example.net for the = second line deliberate? Are either or both of these intended to be the doma= in of the SSP or the domain of the PBX? >=20 > If we go with a scheme that allows the requestor to indicate=20 > which URIs it is requesting for, we might also include some=20 > kind of transform to go with each of the URIs. For example,=20 > we could define a syntax whereby a MARTINI request ends up=20 > associating a range-of-URI indicator like=20 > "sip:214329{wildcard pattern meaning 4=20 > digits}@ssp.example.com"=20 > =20 > with "sip:pbx-110-{pattern meaning put those 4 digits=20 > here}@192.168.1.198"=20 > . [JRE] How would all this work when the PBX mints a temporary GRUU (based on= the PBX's domain name), and subsequently an inbound request to that GRUU n= eeds to be routed to the PBX? The PBX cannot predict all possible GRUU valu= es and include them in the REGISTER request. >=20 >=20 >=20 > 5.3 Routing for explicit/implicitly registered AOR > =09 >=20 >=20 > I think we need to be able to do this without middleboxes,=20 > and without violating SIP's rules about being authoritative=20 > for the requests that a proxy retargets. The strawman=20 > proposal I describe above does not exhibit the problem=20 > described in 5.3. Of course, neither does any well-designed=20 > solution. I think the stuff in the field that includes the=20 > SSP's domain in the R-URI bound for the PBX is simply poorly=20 > designed and insufficiently thought out. [JRE] Yes, but this depends on whether the AOR in the Request-URI uses the = PBX's domain or the SSP's domain. Consider the different scenario where a l= ocal UA on the PBX issues a request to one of the PBX's AORs. The Request-U= RI in that case must contain the domain of the PBX (which could be a sub-do= main of the SSP, assigned to the PBX) - otherwise, according to normal SIP = rules, the PBX would route it to the SSP, which would be wrong (the request= is targeting a destination on the PBX). So likewise requests from the SSP = targeting an AOR on the PBX must have the PBX's domain in the Request-URI. = I guess in your example the PBX's IP address is a substitute for the PBX's = domain name, and that would satisfy this. However, I think I still have a p= reference for the AOR (e.g., sip:12345@pbx.example.com) rather than contact= (e.g., sip:pbx-100-12345@pbx.example.com) being in the Request-URI, so tha= t the PBX can handle the request just as if it had come from another source= (e.g., a local UA). >=20 > In other words, the issue in 5.3 is one of poorly-engineered=20 > implementations, and therefore IRRELEVANT. >=20 >=20 >=20 > 6.1 Avoidance of authorization policy mismatch > =09 >=20 >=20 > IRRELEVANT. I don't think we need to codify the type of=20 > authorization described in this section, as such policies=20 > necessarily limit the flexibility of SIP PBX implementations.=20 > It is quite useful to include state information in the=20 > Contact header field that can be extracted in future=20 > requests. if the SSP policy doesn't allow this kind of valid=20 > use of Contact URIs, then we've lost a rather elegant mechanism. [JRE] Yes, an outbound request could contain a temporary GRUU, for example,= in the contact header field, and the From/PAI could contain a URI from out= side the PBX's domain (where the PBX is forwarding a request from another d= omain). Authorisation of the request should be based on authentication of t= he PBX from which it is received (e.g., based on delivery over an authentic= ated TLS transport) rather than on From/PAI/Contact header field contents i= n that request. >=20 >=20 >=20 > 6.2. Avoidance of PAU mismatch > =09 >=20 >=20 > IRRELEVANT, for the reasons I enumerate under 4.2-4.4, above. >=20 >=20 >=20 > 6.3. Trust domain clarification > =09 >=20 >=20 > I think this isn't just IRRELEVANT -- I think it's out of=20 > scope for the working group. [JRE] I tend to agree. John From bernard_aboba@hotmail.com Tue Jan 5 06:00:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F053A685A for ; Tue, 5 Jan 2010 06:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgXhbmef8YoR for ; Tue, 5 Jan 2010 06:00:53 -0800 (PST) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by core3.amsl.com (Postfix) with ESMTP id 4111428C0E4 for ; Tue, 5 Jan 2010 06:00:53 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 06:00:52 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 5 Jan 2010 06:01:20 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01CA8DCC.812179E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqNbqiyNBYPV04sQ9KohYD1s12PaQAoNhYw Content-Language: en-us X-OriginalArrivalTime: 05 Jan 2010 14:00:52.0173 (UTC) FILETIME=[7DEBA7D0:01CA8E0F] Subject: [martini] Slides and additional Agenda items X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 14:00:54 -0000 ------=_NextPart_000_018B_01CA8DCC.812179E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you are intending to present at the Virtual Interim, we would like to get your slides no later than Wednesday, January 6, 2010 in order to make sure that they are available online. Also, if you would like agenda time, please let myself or Spencer know ASAP. ------=_NextPart_000_018B_01CA8DCC.812179E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are intending to present at the Virtual = Interim, we would like to get your slides no later than Wednesday, January 6, 2010 = in order to make sure that they are available online. 

 

Also, if you would like agenda time, please let = myself or Spencer know ASAP. 

------=_NextPart_000_018B_01CA8DCC.812179E0-- From david.middleton@nsn.com Tue Jan 5 06:40:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17F43A693A for ; Tue, 5 Jan 2010 06:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPm6Ewsf8p3c for ; Tue, 5 Jan 2010 06:40:14 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 881553A6812 for ; Tue, 5 Jan 2010 06:40:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o05Ee7nL009024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2010 15:40:08 +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 o05Ee7ub002473; Tue, 5 Jan 2010 15:40:07 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 15:40:07 +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, 5 Jan 2010 08:39:38 -0600 Message-ID: <159B27ECF9D16E40BD7ABD5778522B0103B74F77@USCHEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini]draft-kaplan-martini-mixing-problems: solution requirements? Thread-Index: AcqIFqukGaGtwsm6Tuij11Ea29pLhQFyo5lQAArUExA= References: <4B394119.4040502@nostrum.com> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Elwell, John" , "Adam Roach" , X-OriginalArrivalTime: 05 Jan 2010 14:40:07.0444 (UTC) FILETIME=[F9C57D40:01CA8E14] Cc: Bernard Aboba Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 14:40:15 -0000 I agree with Adam's designations of REQUIRED/IRRELEVANT however I support John in not allowing the IP-PBX to change the identities it wishes to implicitly register. See [DM] below for more on this as well as another comment. David -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of ext Elwell, John Sent: Tuesday, January 05, 2010 4:36 AM To: Adam Roach; martini@ietf.org Cc: Bernard Aboba Subject: Re: [martini]draft-kaplan-martini-mixing-problems: solution requirements? Thanks to Bernard for highlighting the issues and to Adam for his initial response. My thoughts are interleaved below. =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 28 December 2009 23:37 > To: martini@ietf.org > Cc: Bernard Aboba > Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > solution requirements? >=20 > On 12/28/09 12:53 AM, Bernard Aboba wrote:=20 >=20 > Currently, these sections articulate the issues, but=20 > don't make recommendations as to which of the issues a=20 > potential solution needs to solve. Some of the issues are=20 > indicated as open in the solution proposals (e.g. open=20 > question on PAU/Wildcard syntax in=20 > draft-kaplan-martini-shaken-implicit-registrations) so this=20 > is not just a rhetorical question.=20 > =09 > Here's a list of the Issues described in Sections 4, 5 & 6.=20 > =09 > 4.1. Explicit Indication of Multiple AOR Registration > =09 >=20 >=20 > I think this is REQUIRED. [JRE] Agreed. >=20 >=20 >=20 > 4.2-4.4: Usage of P-Associated URI > a. Inclusion of PAU > b. Avoidance of SIP Response fragmentation > 1. Non-wildcard mitigation > 2. Support for Wildcard syntax > 3. Compatibility of Wildcard syntax with TEL URI > c. Defined behavior of IP-PBX on PAU mismatch > =09 >=20 >=20 > I don't think we want to rely on PAU behavior to make a=20 > multiple registration solution work. The definition in=20 > RFC3455 is pretty well constrained to an exhaustive=20 > enumeration of identities, which is not appropriate for the=20 > kind of use cases MARTINI is discussing. Even more=20 > importantly, it was meant for something rather different than=20 > MARTINI's problem space: multiple identities that=20 > semantically mean *exactly* the same *user*. Not billing=20 > entity, but actual *user*. >=20 > So, I think all the PAU issues are IRRELEVANT with regards to=20 > PAU itself. [JRE]I don't want to see a solution that relies on PAU. >=20 > However, I think we need to carefully consider the semantic=20 > issues that are implied by these sections. Things like: >=20 >=20 > * Who designates which URIs the request is attempting to=20 > register? For example, if a company has a single PBX and=20 > decides to split its users between two different PBXes (say,=20 > at different sites) -- does it need to get the SSP to=20 > reprovision the URIs associated with its implicit=20 > registrations? Or would it make more sense for the request to=20 > indicate which URIs it was attempting to register? This would=20 > allow the company to move URIs around between its own PBXes=20 > without a provisioning action at the SSP. [JRE] I don't think this is a problem we necessarily need to solve at this stage. It would involve issues such as what if two PBXs try to register overlapping sets of AORs, and what if one of the AORs in the request is one that the PBX is not entitled to use. Provisioning will in any case be needed at the SSP whenever a new AOR is added to (or removed from) the total pool, so requiring provisioning also for the case where an AOR moves PBX is not out of the question. [DM] This is a nice goal but it would be dependent on multiple PBXs being hosted by the same SSP Registrar short of developing additional interfaces between systems. I agree with John that it should be out of scope of this working group. > =09 > =09 > * How does the UAC know which URIs have just been=20 > registered? If they don't match what it expects, how does it=20 > react? Note that this problem goes away if we allow the user=20 > to designate which URIs they're attempting to register in the=20 > request. Granted, it pushes the responsibility of verifying=20 > the URIs onto the SSP equipment, but at least it can send an=20 > error response if the requestor is not authorized to use the=20 > specified URIs. > =09 > =09 > * Response size is a real concern, since there's no way=20 > to switch from UDP to TCP at the UAS side when responses are=20 > too large for the MTU. On the other hand, the requestor can=20 > always elect to use TCP if the request is too large. This,=20 > again, points to having the requestor indicate the URIs to be=20 > used instead of the responder.=20 >=20 > Which is to say: I think the implicit model currently under=20 > discussion in the problems and implicit-registration drafts=20 > is going about the issue backwards. I believe that there are=20 > a number of reasons it makes much more sense to have an=20 > explicit model in which the PBX tells the SSP which URIs it=20 > is attempting to register, and the SSP accepts or denies the=20 > request based on authorization policy. >=20 >=20 >=20 > 5.1 Retaining Target Info > 5.2 Contact-URI handling > a. Request-URI > b. Route Header > =09 >=20 >=20 > I think retaining all the information that the PBX used to=20 > indicate itself -- the "Contact" header field in Hadriel's=20 > drafts -- is REQUIRED. Clearly, we also need the ability to=20 > tell which extension is being addressed (i.e., this is=20 > REQUIRED as well). >=20 > I'm less concerned about the mechanisms used to convey this=20 > information. Ideally, it would be as consistent with normal=20 > handling as is possible -- meaning that the Request URI is=20 > semantically the information the PBX used to indicate itself=20 > (again, the "Contact" header field in Hadriel's proposals). [JRE] It depends what you mean by "normal handling". From the PBX's point of view, it would be more normal for the target AOR to appear in the Request-URI - that is where it would appear if the request had come from another source, e.g., a local UA, another PBX in the enterprise network, or another domain with which the PBX peers. >=20 > When you think about how currently-deployed multiline SIP=20 > phones handle this situation, they'll usually use the user=20 > portion of the Contact header field to keep track of which of=20 > its several identities a request is associated with. For=20 > example, a phone may register the AOR "sip:adam@example.com"=20 > with a Contact of=20 > "sip:line1@192.168.1.15" , and=20 > register "sip:some-other-id@example.net"=20 > with a Contact of=20 > "sip:line2@192.168.1.15" . That's=20 > kind of nice, because it lets the end device correlate=20 > information according to its own local scheme. [JRE] Is the use of example.com for the first line and example.net for the second line deliberate? Are either or both of these intended to be the domain of the SSP or the domain of the PBX? >=20 > If we go with a scheme that allows the requestor to indicate=20 > which URIs it is requesting for, we might also include some=20 > kind of transform to go with each of the URIs. For example,=20 > we could define a syntax whereby a MARTINI request ends up=20 > associating a range-of-URI indicator like=20 > "sip:214329{wildcard pattern meaning 4=20 > digits}@ssp.example.com"=20 > =20 > with "sip:pbx-110-{pattern meaning put those 4 digits=20 > here}@192.168.1.198"=20 > . [JRE] How would all this work when the PBX mints a temporary GRUU (based on the PBX's domain name), and subsequently an inbound request to that GRUU needs to be routed to the PBX? The PBX cannot predict all possible GRUU values and include them in the REGISTER request. >=20 >=20 >=20 > 5.3 Routing for explicit/implicitly registered AOR > =09 >=20 >=20 > I think we need to be able to do this without middleboxes,=20 > and without violating SIP's rules about being authoritative=20 > for the requests that a proxy retargets. The strawman=20 > proposal I describe above does not exhibit the problem=20 > described in 5.3. Of course, neither does any well-designed=20 > solution. I think the stuff in the field that includes the=20 > SSP's domain in the R-URI bound for the PBX is simply poorly=20 > designed and insufficiently thought out. [JRE] Yes, but this depends on whether the AOR in the Request-URI uses the PBX's domain or the SSP's domain. Consider the different scenario where a local UA on the PBX issues a request to one of the PBX's AORs. The Request-URI in that case must contain the domain of the PBX (which could be a sub-domain of the SSP, assigned to the PBX) - otherwise, according to normal SIP rules, the PBX would route it to the SSP, which would be wrong (the request is targeting a destination on the PBX). So likewise requests from the SSP targeting an AOR on the PBX must have the PBX's domain in the Request-URI. I guess in your example the PBX's IP address is a substitute for the PBX's domain name, and that would satisfy this. However, I think I still have a preference for the AOR (e.g., sip:12345@pbx.example.com) rather than contact (e.g., sip:pbx-100-12345@pbx.example.com) being in the Request-URI, so that the PBX can handle the request just as if it had come from another source (e.g., a local UA). >=20 > In other words, the issue in 5.3 is one of poorly-engineered=20 > implementations, and therefore IRRELEVANT. >=20 >=20 >=20 > 6.1 Avoidance of authorization policy mismatch > =09 >=20 >=20 > IRRELEVANT. I don't think we need to codify the type of=20 > authorization described in this section, as such policies=20 > necessarily limit the flexibility of SIP PBX implementations.=20 > It is quite useful to include state information in the=20 > Contact header field that can be extracted in future=20 > requests. if the SSP policy doesn't allow this kind of valid=20 > use of Contact URIs, then we've lost a rather elegant mechanism. [JRE] Yes, an outbound request could contain a temporary GRUU, for example, in the contact header field, and the From/PAI could contain a URI from outside the PBX's domain (where the PBX is forwarding a request from another domain). Authorisation of the request should be based on authentication of the PBX from which it is received (e.g., based on delivery over an authenticated TLS transport) rather than on From/PAI/Contact header field contents in that request. [DM] While authorization policy mismatch is a valid concern, it is IRRELEVANT to providing reachability information. SSP problems handling changing contact headers can happen irrespective of multiple users (e.g. IP-PBX). >=20 >=20 >=20 > 6.2. Avoidance of PAU mismatch > =09 >=20 >=20 > IRRELEVANT, for the reasons I enumerate under 4.2-4.4, above. >=20 >=20 >=20 > 6.3. Trust domain clarification > =09 >=20 >=20 > I think this isn't just IRRELEVANT -- I think it's out of=20 > scope for the working group. [JRE] I tend to agree. John _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Tue Jan 5 06:41:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC9828C0E4 for ; Tue, 5 Jan 2010 06:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4+pF+hcYTwj for ; Tue, 5 Jan 2010 06:41:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5D8363A6812 for ; Tue, 5 Jan 2010 06:41:40 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o05EfbWl071858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 08:41:38 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B434FA1.40300@nostrum.com> Date: Tue, 05 Jan 2010 08:41:37 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: Bernard Aboba , "martini@ietf.org" Subject: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 14:41:42 -0000 I'm breaking out this issue into its own thread, since I think it's fundamental to getting the solution correct. On 1/5/10 03:36, Jan 5, Elwell, John wrote: > >> * Who designates which URIs the request is attempting to >> register? For example, if a company has a single PBX and >> decides to split its users between two different PBXes (say, >> at different sites) -- does it need to get the SSP to >> reprovision the URIs associated with its implicit >> registrations? Or would it make more sense for the request to >> indicate which URIs it was attempting to register? This would >> allow the company to move URIs around between its own PBXes >> without a provisioning action at the SSP. >> > [JRE] I don't think this is a problem we necessarily need to solve at this stage. Quite to the contrary -- I think the assumption that the SSP makes the determination is a fundamental fallacy in the current suite of documents. Fixing this problem will require different procedures than are proposed at the moment. We need to get the semantics correct before we start jumping into protocol and syntax. At this point, we seem to have taken as a given that "the way to do it" should be modeled off the hacked-together ad hoc solutions that people have thrown together in the field. Duct tape and bailing wire may keep you going for a while in a pinch, but you don't explicitly call for them on blueprints when you sit down to design a system. > It would involve issues such as what if two PBXs try to register overlapping sets of AORs Oddly enough, SIP handles multiple registrations for a single AOR just fine now. In fact, even Hadriel's current set of proposals talks about multiple registrations for an AOR. It's just a basic, key part of SIP's rendezvous model. I fear that this highlights one of the problems MARTINI must overcome: people are thinking of this problem space too much in terms of "how can we make this work like 1960s PBX systems?," not "how do we adapt SIP to perform multiple AOR registrations in a single transaction?" If you are considering the first question, overlapping AORs would be a real problem, since that's not how the PSTN works. If you are considering the second question, the very concept of "overlapping AORs" is nonsense, since multiple registrations for a single AOR are so very, very fundamental to the core functioning of SIP. > and what if one of the AORs in the request is one that the PBX is not entitled to use. Which is the mirror problem to "what if one of the AORs in the response is one that PBX is not prepared to handle?" We need to fix it either way. At least with the "PBX requestor" model, the problem is discovered mid-transaction, and can be addressed with proper error handling. With the mechanisms in Hadiel's document, the error is only discovered after the binding is established. Even worse, there is no clear recovery path, and no flexibility in handling the situation. > Provisioning will in any case be needed at the SSP whenever a new AOR is added to (or removed from) the total pool, so requiring provisioning also for the case where an AOR moves PBX is not out of the question. > I don't want to invoke a provisioning action because one of my employees is traveling from the Dallas office to the Kansas office for two days. Based on the SSPs I've worked with, by the time the ticket is closed, he'll be back in Dallas anyway. /a From adam@nostrum.com Tue Jan 5 07:03:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A87A3A693E for ; Tue, 5 Jan 2010 07:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0-n1Q-g-ZMN for ; Tue, 5 Jan 2010 07:03:18 -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 8F6313A693B for ; Tue, 5 Jan 2010 07:03:17 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o05F3B23073597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 09:03:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4354AF.8060500@nostrum.com> Date: Tue, 05 Jan 2010 09:03:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 15:03:19 -0000 On 1/5/10 03:36, Jan 5, Elwell, John wrote: > >> 5.1 Retaining Target Info >> 5.2 Contact-URI handling >> a. Request-URI >> b. Route Header >> =09 >> >> >> I think retaining all the information that the PBX used to >> indicate itself -- the "Contact" header field in Hadriel's >> drafts -- is REQUIRED. Clearly, we also need the ability to >> tell which extension is being addressed (i.e., this is >> REQUIRED as well). >> >> I'm less concerned about the mechanisms used to convey this >> information. Ideally, it would be as consistent with normal >> handling as is possible -- meaning that the Request URI is >> semantically the information the PBX used to indicate itself >> (again, the "Contact" header field in Hadriel's proposals). >> =20 > [JRE] It depends what you mean by "normal handling". I mean registrar processing as described in RFC 3261. > From the PBX's point of view, it would be more normal for the target= AOR to appear in the Request-URI - that is where it would appear if the = request had come from another source, e.g., a local UA, another PBX in th= e enterprise network, or another domain with which the PBX peers. > =20 You're confusing RFC3263 routing with registrar routing. They're very=20 different things. And since we're talking about PBXes that have=20 effectively removed themselves from the 3263 routing model, "normal"=20 behavior is registrar behavior. >> When you think about how currently-deployed multiline SIP >> phones handle this situation, they'll usually use the user >> portion of the Contact header field to keep track of which of >> its several identities a request is associated with. For >> example, a phone may register the AOR "sip:adam@example.com" >> with a Contact of >> "sip:line1@192.168.1.15" , and >> register "sip:some-other-id@example.net" >> with a Contact of >> "sip:line2@192.168.1.15" . That's >> kind of nice, because it lets the end device correlate >> information according to its own local scheme. >> =20 > [JRE] Is the use of example.com for the first line and example.net for = the second line deliberate? Are either or both of these intended to be th= e domain of the SSP or the domain of the PBX? > =20 The answer to your first question is "it's irrelevant." the second=20 question is nonsense -- I was giving an example of a SIP terminal in a=20 generic SIP network, without anything that one would reasonably consider = a PBX or an SSP. Example.com and example.net are both registrars. Which=20 is not to say they are PBXes. They're registrars. Read nothing more into = that. >> If we go with a scheme that allows the requestor to indicate >> which URIs it is requesting for, we might also include some >> kind of transform to go with each of the URIs. For example, >> we could define a syntax whereby a MARTINI request ends up >> associating a range-of-URI indicator like >> "sip:214329{wildcard pattern meaning 4 >> digits}@ssp.example.com" >> >> with "sip:pbx-110-{pattern meaning put those 4 digits >> here}@192.168.1.198" >> . >> =20 > [JRE] How would all this work when the PBX mints a temporary GRUU (base= d on the PBX's domain name), and subsequently an inbound request to that = GRUU needs to be routed to the PBX? The PBX cannot predict all possible G= RUU values and include them in the REGISTER request. > =20 Yep, we'll have to define special procedures for GRUUs. This problem=20 arises regardless of whether the SSP or the PBX selects the AORs. I'm=20 comfortable that we can solve it for both cases, and have some ideas in=20 this space. But I don't want to rathole on that issue right now, so I'm=20 not describing them at the moment. >> >> >> 5.3 Routing for explicit/implicitly registered AOR >> =09 >> >> >> I think we need to be able to do this without middleboxes, >> and without violating SIP's rules about being authoritative >> for the requests that a proxy retargets. The strawman >> proposal I describe above does not exhibit the problem >> described in 5.3. Of course, neither does any well-designed >> solution. I think the stuff in the field that includes the >> SSP's domain in the R-URI bound for the PBX is simply poorly >> designed and insufficiently thought out. >> =20 > [JRE] Yes, but this depends on whether the AOR in the Request-URI uses = the PBX's domain or the SSP's domain. Consider the different scenario whe= re a local UA on the PBX issues a request to one of the PBX's AORs. The R= equest-URI in that case must contain the domain of the PBX (which could b= e a sub-domain of the SSP, assigned to the PBX) - otherwise, according to= normal SIP rules, the PBX would route it to the SSP, which would be wron= g (the request is targeting a destination on the PBX). So likewise reques= ts from the SSP targeting an AOR on the PBX must have the PBX's domain in= the Request-URI. I guess in your example the PBX's IP address is a subst= itute for the PBX's domain name, and that would satisfy this. However, I = think I still have a preference for the AOR (e.g., sip:12345@pbx.example.= com) rather than contact (e.g., sip:pbx-100-12345@pbx.example.com) being = in the Request-URI, so that the PBX can handle the request just as if it = had come from another source (e.g., a local UA). > =20 I don't think that works the way you think it does. In your example,=20 what do you get when you run "pbx.example.com" through 3263 resolution=20 rules? Does it point to the SSP or the PBX? If it points to the PBX,=20 then the justification described by=20 draft-kaplan-martini-shaken-implicit-registrations goes away. That=20 particular PBX is not a candidate for MARTINI procedures. /a From john.elwell@siemens-enterprise.com Tue Jan 5 07:48:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B9D28C0FF for ; Tue, 5 Jan 2010 07:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LASYRCKv+B18 for ; Tue, 5 Jan 2010 07:48:43 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id ADFCB28C13E for ; Tue, 5 Jan 2010 07:48:42 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-442790; Tue, 5 Jan 2010 16:48:40 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B263A1EB828F; Tue, 5 Jan 2010 16:48:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 16:48:41 +0100 From: "Elwell, John" To: Adam Roach Date: Tue, 5 Jan 2010 16:48:38 +0100 Thread-Topic: Who designates AORs? (was Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOFTOFrJgGNBKuTZ2wGm0Hj55a2gACH+jg Message-ID: References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> In-Reply-To: <4B434FA1.40300@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 15:48:44 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 January 2010 14:42 > To: Elwell, John > Cc: martini@ietf.org; Bernard Aboba > Subject: Who designates AORs? (was Re: [martini]=20 > draft-kaplan-martini-mixing-problems: solution requirements?) >=20 > I'm breaking out this issue into its own thread, since I think it's=20 > fundamental to getting the solution correct. >=20 >=20 > On 1/5/10 03:36, Jan 5, Elwell, John wrote: > > > >> * Who designates which URIs the request is attempting to > >> register? For example, if a company has a single PBX and > >> decides to split its users between two different PBXes (say, > >> at different sites) -- does it need to get the SSP to > >> reprovision the URIs associated with its implicit > >> registrations? Or would it make more sense for the request to > >> indicate which URIs it was attempting to register? This would > >> allow the company to move URIs around between its own PBXes > >> without a provisioning action at the SSP. > >> =20 > > [JRE] I don't think this is a problem we necessarily need=20 > to solve at this stage. >=20 > Quite to the contrary -- I think the assumption that the SSP=20 > makes the=20 > determination is a fundamental fallacy in the current suite of=20 > documents. Fixing this problem will require different procedures than=20 > are proposed at the moment. >=20 > We need to get the semantics correct before we start jumping into=20 > protocol and syntax. At this point, we seem to have taken as a given=20 > that "the way to do it" should be modeled off the=20 > hacked-together ad hoc=20 > solutions that people have thrown together in the field. Duct=20 > tape and=20 > bailing wire may keep you going for a while in a pinch, but you don't=20 > explicitly call for them on blueprints when you sit down to=20 > design a system. >=20 >=20 > > It would involve issues such as what if two PBXs try to=20 > register overlapping sets of AORs >=20 > Oddly enough, SIP handles multiple registrations for a single=20 > AOR just=20 > fine now. In fact, even Hadriel's current set of proposals=20 > talks about=20 > multiple registrations for an AOR. It's just a basic, key=20 > part of SIP's=20 > rendezvous model. >=20 > I fear that this highlights one of the problems MARTINI must=20 > overcome:=20 > people are thinking of this problem space too much in terms=20 > of "how can=20 > we make this work like 1960s PBX systems?," not "how do we=20 > adapt SIP to=20 > perform multiple AOR registrations in a single transaction?"=20 > If you are=20 > considering the first question, overlapping AORs would be a real=20 > problem, since that's not how the PSTN works. If you are=20 > considering the=20 > second question, the very concept of "overlapping AORs" is nonsense,=20 > since multiple registrations for a single AOR are so very, very=20 > fundamental to the core functioning of SIP. >=20 > > and what if one of the AORs in the request is one that the=20 > PBX is not entitled to use. >=20 > Which is the mirror problem to "what if one of the AORs in=20 > the response=20 > is one that PBX is not prepared to handle?" We need to fix it=20 > either way. >=20 > At least with the "PBX requestor" model, the problem is discovered=20 > mid-transaction, and can be addressed with proper error=20 > handling. With=20 > the mechanisms in Hadiel's document, the error is only=20 > discovered after=20 > the binding is established. Even worse, there is no clear=20 > recovery path,=20 > and no flexibility in handling the situation. >=20 > > Provisioning will in any case be needed at the SSP whenever=20 > a new AOR is added to (or removed from) the total pool, so=20 > requiring provisioning also for the case where an AOR moves=20 > PBX is not out of the question. > > =20 >=20 > I don't want to invoke a provisioning action because one of=20 > my employees=20 > is traveling from the Dallas office to the Kansas office for=20 > two days.=20 > Based on the SSPs I've worked with, by the time the ticket is closed,=20 > he'll be back in Dallas anyway. [JRE] I guess there are two ways to do this temporary move type scenario fr= om PBX1 to PBX2. One is as you suggest, you register the fact with the SSP = so that SSP forwards all incoming requests to PBX2 instead of PBX1, until s= uch time as PBX2 de-registers that AOR and PBX1 re-registers it. The other = way is for all incoming requests to continue to arrive at PBX1 and for PBX1= to route onwards (within the enterprise infrastructure) to PBX2. This is t= he way it would work if the source of the request were a local UA on PBX1 -= PBX 1 would just route it to PBX2. So given that PBX1 has this capability,= why can't it use this for requests arriving from the SSP? John >=20 > /a > = From john.elwell@siemens-enterprise.com Tue Jan 5 08:09:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96843A688D for ; Tue, 5 Jan 2010 08:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 DUkeCCZYq1dL for ; Tue, 5 Jan 2010 08:09:23 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3A1F33A682B for ; Tue, 5 Jan 2010 08:09:22 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-443099; Tue, 5 Jan 2010 17:09:19 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C70B41EB8274; Tue, 5 Jan 2010 17:09:19 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 17:09:20 +0100 From: "Elwell, John" To: Adam Roach Date: Tue, 5 Jan 2010 17:09:18 +0100 Thread-Topic: [martini] draft-kaplan-martini-mixing-problems: solution requirements? Thread-Index: AcqOGDfEbqM1PaYtQAiuTAAf4TikhwABzazQ Message-ID: References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> In-Reply-To: <4B4354AF.8060500@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:09:24 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 January 2010 15:03 > To: Elwell, John > Cc: martini@ietf.org; Bernard Aboba > Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > solution requirements? >=20 > On 1/5/10 03:36, Jan 5, Elwell, John wrote: > > > >> 5.1 Retaining Target Info > >> 5.2 Contact-URI handling > >> a. Request-URI > >> b. Route Header > >> =09 > >> > >> > >> I think retaining all the information that the PBX used to > >> indicate itself -- the "Contact" header field in Hadriel's > >> drafts -- is REQUIRED. Clearly, we also need the ability to > >> tell which extension is being addressed (i.e., this is > >> REQUIRED as well). > >> > >> I'm less concerned about the mechanisms used to convey this > >> information. Ideally, it would be as consistent with normal > >> handling as is possible -- meaning that the Request URI is > >> semantically the information the PBX used to indicate itself > >> (again, the "Contact" header field in Hadriel's proposals). > >> =20 > > [JRE] It depends what you mean by "normal handling". >=20 > I mean registrar processing as described in RFC 3261. >=20 > > From the PBX's point of view, it would be more normal=20 > for the target AOR to appear in the Request-URI - that is=20 > where it would appear if the request had come from another=20 > source, e.g., a local UA, another PBX in the enterprise=20 > network, or another domain with which the PBX peers. > > =20 >=20 > You're confusing RFC3263 routing with registrar routing. They're very=20 > different things. And since we're talking about PBXes that have=20 > effectively removed themselves from the 3263 routing model, "normal"=20 > behavior is registrar behavior. [JRE] I don't understand your reasoning. For both registrar routing and 326= 3 routing, you start with what is in the Request-URI (assuming there is no = Route header) and resolve that. Whether it is resolved by DNS look-up or by= other means is irrelevant - the Request-URI is the starting point. With wh= at you propose, the PBX would have first to manipulate the Request-URI to g= et it back to an AOR, in order then to carry out whatever form or routing i= t would normally do. >=20 > >> When you think about how currently-deployed multiline SIP > >> phones handle this situation, they'll usually use the user > >> portion of the Contact header field to keep track of which of > >> its several identities a request is associated with. For > >> example, a phone may register the AOR "sip:adam@example.com" > >> with a Contact of > >> "sip:line1@192.168.1.15" , and > >> register "sip:some-other-id@example.net" > >> with a Contact of > >> "sip:line2@192.168.1.15" . That's > >> kind of nice, because it lets the end device correlate > >> information according to its own local scheme. > >> =20 > > [JRE] Is the use of example.com for the first line and=20 > example.net for the second line deliberate? Are either or=20 > both of these intended to be the domain of the SSP or the=20 > domain of the PBX? > > =20 >=20 >=20 > The answer to your first question is "it's irrelevant." the second=20 > question is nonsense -- I was giving an example of a SIP=20 > terminal in a=20 > generic SIP network, without anything that one would=20 > reasonably consider=20 > a PBX or an SSP. Example.com and example.net are both=20 > registrars. Which=20 > is not to say they are PBXes. They're registrars. Read=20 > nothing more into=20 > that. >=20 >=20 > >> If we go with a scheme that allows the requestor to indicate > >> which URIs it is requesting for, we might also include some > >> kind of transform to go with each of the URIs. For example, > >> we could define a syntax whereby a MARTINI request ends up > >> associating a range-of-URI indicator like > >> "sip:214329{wildcard pattern meaning 4 > >> digits}@ssp.example.com" > >> > >> with "sip:pbx-110-{pattern meaning put those 4 digits > >> here}@192.168.1.198" > >> . > >> =20 > > [JRE] How would all this work when the PBX mints a=20 > temporary GRUU (based on the PBX's domain name), and=20 > subsequently an inbound request to that GRUU needs to be=20 > routed to the PBX? The PBX cannot predict all possible GRUU=20 > values and include them in the REGISTER request. > > =20 >=20 >=20 > Yep, we'll have to define special procedures for GRUUs. This problem=20 > arises regardless of whether the SSP or the PBX selects the AORs. I'm=20 > comfortable that we can solve it for both cases, and have=20 > some ideas in=20 > this space. But I don't want to rathole on that issue right=20 > now, so I'm=20 > not describing them at the moment. >=20 >=20 > >> > >> > >> 5.3 Routing for explicit/implicitly registered AOR > >> =09 > >> > >> > >> I think we need to be able to do this without middleboxes, > >> and without violating SIP's rules about being authoritative > >> for the requests that a proxy retargets. The strawman > >> proposal I describe above does not exhibit the problem > >> described in 5.3. Of course, neither does any well-designed > >> solution. I think the stuff in the field that includes the > >> SSP's domain in the R-URI bound for the PBX is simply poorly > >> designed and insufficiently thought out. > >> =20 > > [JRE] Yes, but this depends on whether the AOR in the=20 > Request-URI uses the PBX's domain or the SSP's domain.=20 > Consider the different scenario where a local UA on the PBX=20 > issues a request to one of the PBX's AORs. The Request-URI in=20 > that case must contain the domain of the PBX (which could be=20 > a sub-domain of the SSP, assigned to the PBX) - otherwise,=20 > according to normal SIP rules, the PBX would route it to the=20 > SSP, which would be wrong (the request is targeting a=20 > destination on the PBX). So likewise requests from the SSP=20 > targeting an AOR on the PBX must have the PBX's domain in the=20 > Request-URI. I guess in your example the PBX's IP address is=20 > a substitute for the PBX's domain name, and that would=20 > satisfy this. However, I think I still have a preference for=20 > the AOR (e.g., sip:12345@pbx.example.com) rather than contact=20 > (e.g., sip:pbx-100-12345@pbx.example.com) being in the=20 > Request-URI, so that the PBX can handle the request just as=20 > if it had come from another source (e.g., a local UA). > > =20 >=20 > I don't think that works the way you think it does. In your example,=20 > what do you get when you run "pbx.example.com" through 3263=20 > resolution=20 > rules? Does it point to the SSP or the PBX? If it points to the PBX,=20 > then the justification described by=20 > draft-kaplan-martini-shaken-implicit-registrations goes away. That=20 > particular PBX is not a candidate for MARTINI procedures. [JRE] Internally the PBX would be able to route on pbx.example.com (it woul= d treat it as its own domain, as it would if its own IP address were in the= domain part). This does not necessarily mean that pbx.example.com is publi= shed to the whole world so that they can get there without using MARTINI pr= ocedures. For most purposes today, E.164 numbers are used, so a request cou= ld start off as addressed to sip:+123456789@ssp.example.net (or tel:+123456= 79, which would get resolved to sip:+123456789@ssp.example.net). The SSP (s= sp.example.net) would use MARTINI procedures to get it to the PBX. For deli= very to the PBX you need something different in the domain part (e.g., IP a= ddress or pbx.example.com) so that, on receipt, the PBX doesn't simply rout= e it back to the SSP. John From pkyzivat@cisco.com Tue Jan 5 08:14:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719463A688D for ; Tue, 5 Jan 2010 08:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7sRt-Eb-v-5 for ; Tue, 5 Jan 2010 08:14:09 -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 EC7223A67E3 for ; Tue, 5 Jan 2010 08:14:08 -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: ApoEAOzzQkurR7Ht/2dsb2JhbAC/RJRXhDAE X-IronPort-AV: E=Sophos;i="4.47,506,1257120000"; d="scan'208";a="461720492" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 05 Jan 2010 16:13:08 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o05GD8t5008720; Tue, 5 Jan 2010 16:13:08 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:13:07 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:13:07 -0600 Message-ID: <4B436512.7070309@cisco.com> Date: Tue, 05 Jan 2010 11:13:06 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> In-Reply-To: <4B434FA1.40300@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2010 16:13:07.0595 (UTC) FILETIME=[F7CCF5B0:01CA8E21] Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:14:10 -0000 I agree with a lot of what Adam says here. But, is it reasonable to expect a sip request to convey several hundred AORs? (And what if it becomes several thousand?) This is out of the scope of what sip requests were designed to handle. If that path is taken, then next people will be asking to encode those more tightly, such as by specifying ranges of numbers. But of course that won't work for non-numeric addresses. It starts to look very ugly. Regarding the "overlapping registrations", I agree with Adam that allowing multiple PBXs to "own" the same number is a feature. In Adam's example of employee going from Dallas to Kansas City for a few days it is equally likely that the employee's desk phone is still registered in Dallas, along side the temporary (or soft) phone that person is using in KC, so that they will both ring. That's ok. Thanks, Paul Adam Roach wrote: > I'm breaking out this issue into its own thread, since I think it's > fundamental to getting the solution correct. > > > On 1/5/10 03:36, Jan 5, Elwell, John wrote: >> >>> * Who designates which URIs the request is attempting to >>> register? For example, if a company has a single PBX and >>> decides to split its users between two different PBXes (say, >>> at different sites) -- does it need to get the SSP to >>> reprovision the URIs associated with its implicit >>> registrations? Or would it make more sense for the request to >>> indicate which URIs it was attempting to register? This would >>> allow the company to move URIs around between its own PBXes >>> without a provisioning action at the SSP. >>> >> [JRE] I don't think this is a problem we necessarily need to solve at >> this stage. > > Quite to the contrary -- I think the assumption that the SSP makes the > determination is a fundamental fallacy in the current suite of > documents. Fixing this problem will require different procedures than > are proposed at the moment. > > We need to get the semantics correct before we start jumping into > protocol and syntax. At this point, we seem to have taken as a given > that "the way to do it" should be modeled off the hacked-together ad hoc > solutions that people have thrown together in the field. Duct tape and > bailing wire may keep you going for a while in a pinch, but you don't > explicitly call for them on blueprints when you sit down to design a > system. > > >> It would involve issues such as what if two PBXs try to register >> overlapping sets of AORs > > Oddly enough, SIP handles multiple registrations for a single AOR just > fine now. In fact, even Hadriel's current set of proposals talks about > multiple registrations for an AOR. It's just a basic, key part of SIP's > rendezvous model. > > I fear that this highlights one of the problems MARTINI must overcome: > people are thinking of this problem space too much in terms of "how can > we make this work like 1960s PBX systems?," not "how do we adapt SIP to > perform multiple AOR registrations in a single transaction?" If you are > considering the first question, overlapping AORs would be a real > problem, since that's not how the PSTN works. If you are considering the > second question, the very concept of "overlapping AORs" is nonsense, > since multiple registrations for a single AOR are so very, very > fundamental to the core functioning of SIP. > >> and what if one of the AORs in the request is one that the PBX is not >> entitled to use. > > Which is the mirror problem to "what if one of the AORs in the response > is one that PBX is not prepared to handle?" We need to fix it either way. > > At least with the "PBX requestor" model, the problem is discovered > mid-transaction, and can be addressed with proper error handling. With > the mechanisms in Hadiel's document, the error is only discovered after > the binding is established. Even worse, there is no clear recovery path, > and no flexibility in handling the situation. > >> Provisioning will in any case be needed at the SSP whenever a new AOR >> is added to (or removed from) the total pool, so requiring >> provisioning also for the case where an AOR moves PBX is not out of >> the question. >> > > I don't want to invoke a provisioning action because one of my employees > is traveling from the Dallas office to the Kansas office for two days. > Based on the SSPs I've worked with, by the time the ticket is closed, > he'll be back in Dallas anyway. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Tue Jan 5 08:26:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1468D3A682B for ; Tue, 5 Jan 2010 08:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 80UOaFWk7H7z for ; Tue, 5 Jan 2010 08:26:00 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CE0423A6803 for ; Tue, 5 Jan 2010 08:25:55 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-443323; Tue, 5 Jan 2010 17:25:54 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0D87C23F0209; Tue, 5 Jan 2010 17:25:54 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 17:25:54 +0100 From: "Elwell, John" To: Paul Kyzivat , Adam Roach Date: Tue, 5 Jan 2010 17:25:52 +0100 Thread-Topic: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOIhzZyh6/PdDnRt2BxRf80lxqoQAATJUw Message-ID: References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> <4B436512.7070309@cisco.com> In-Reply-To: <4B436512.7070309@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: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:26:01 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 05 January 2010 16:13 > To: Adam Roach > Cc: Elwell, John; Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Who designates AORs? (was Re:=20 > draft-kaplan-martini-mixing-problems: solution requirements?) >=20 > I agree with a lot of what Adam says here. >=20 > But, is it reasonable to expect a sip request to convey > several hundred AORs? (And what if it becomes several thousand?) > This is out of the scope of what sip requests were designed to handle. >=20 > If that path is taken, then next people will be asking to=20 > encode those=20 > more tightly, such as by specifying ranges of numbers. But of course=20 > that won't work for non-numeric addresses. It starts to look=20 > very ugly. >=20 > Regarding the "overlapping registrations", I agree with Adam that=20 > allowing multiple PBXs to "own" the same number is a feature. > In Adam's example of employee going from Dallas to Kansas=20 > City for a few=20 > days it is equally likely that the employee's desk phone is still=20 > registered in Dallas, along side the temporary (or soft) phone that=20 > person is using in KC, so that they will both ring. That's ok. [JRE] But there are other ways of making them both ring, i.e., deliver the = request to the Dallas PBX and let that do the parallel forking to the Dalla= s UA and to the KC UA. Just as it would if the source of the request were a= local UA in Dallas. John From adam@nostrum.com Tue Jan 5 08:31:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965EF28C147 for ; Tue, 5 Jan 2010 08:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgWoG35I1H3s for ; Tue, 5 Jan 2010 08:31:52 -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 564D528C13F for ; Tue, 5 Jan 2010 08:31:51 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o05GVlFh080877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 10:31:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B436973.5010703@nostrum.com> Date: Tue, 05 Jan 2010 10:31:47 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Paul Kyzivat References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> <4B436512.7070309@cisco.com> In-Reply-To: <4B436512.7070309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:31:53 -0000 On 1/5/10 10:13, Jan 5, Paul Kyzivat wrote: > I agree with a lot of what Adam says here. > > But, is it reasonable to expect a sip request to convey > several hundred AORs? (And what if it becomes several thousand?) > This is out of the scope of what sip requests were designed to handle. > > If that path is taken, then next people will be asking to encode those > more tightly, such as by specifying ranges of numbers. But of course > that won't work for non-numeric addresses. It starts to look very ugly. Yes, this is one of the most difficult problems that MARTINI must solve. And it's a problem regardless of whether the PBX suggests the AORs to register or the SSP tells the PBX which AORs it has just registered. Some message somewhere is going to have to indicate the AORs involved. We clearly don't do ranges of numbers. But we can do a lot with patterns, which would include ranges of numbers. /a From pkyzivat@cisco.com Tue Jan 5 08:36:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2269C3A692B for ; Tue, 5 Jan 2010 08:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGqg3wOfTn8j for ; Tue, 5 Jan 2010 08:36:24 -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 73DA428C144 for ; Tue, 5 Jan 2010 08:36:22 -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: ApoEAHv5QkutJV2Y/2dsb2JhbAC/W4kNCYtAgkeBaQQ X-IronPort-AV: E=Sophos;i="4.47,506,1257120000"; d="scan'208";a="78422710" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2010 16:36:20 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o05GaKud029540; Tue, 5 Jan 2010 16:36:20 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:36:20 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:36:20 -0600 Message-ID: <4B436A83.40305@cisco.com> Date: Tue, 05 Jan 2010 11:36:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2010 16:36:20.0155 (UTC) FILETIME=[35D4C0B0:01CA8E25] Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:36:25 -0000 Elwell, John wrote: >> I don't think that works the way you think it does. In your example, >> what do you get when you run "pbx.example.com" through 3263 >> resolution >> rules? Does it point to the SSP or the PBX? If it points to the PBX, >> then the justification described by >> draft-kaplan-martini-shaken-implicit-registrations goes away. That >> particular PBX is not a candidate for MARTINI procedures. > [JRE] Internally the PBX would be able to route on pbx.example.com (it would treat it as its own domain, as it would if its own IP address were in the domain part). This does not necessarily mean that pbx.example.com is published to the whole world so that they can get there without using MARTINI procedures. For most purposes today, E.164 numbers are used, so a request could start off as addressed to sip:+123456789@ssp.example.net (or tel:+12345679, which would get resolved to sip:+123456789@ssp.example.net). The SSP (ssp.example.net) would use MARTINI procedures to get it to the PBX. For delivery to the PBX you need something different in the domain part (e.g., IP address or pbx.example.com) so that, on receipt, the PBX doesn't simply route it back to the SSP. I don't buy that logic. If you want requests to pbx.example.com to go through the martini processes, then responsibility for that domain needs to reside with the SSP. What you describe amounts to having a split-DNS, where the resolution of that domain name gets a different answer inside the enterprise than it does outside. I don't find that an appealing direction to go. If you want the pbx to have its own domain name, then it needs to be a different one from the one used to reach its numbers at the SSP. When routing on numbers in the SSP world the domain names are constantly changing in any case. It seems plausible to me that 1-408-555-1234 is initially addressed to sip:1-408-555-1234@ssp1.net, gets routed by ssp1.net to ssp2.net and in the process gets rewritten as sip:1-408-555-1234@ssp2.net, then mapped by ssp2 to sip:1-408-555-1234@pbx.example.ssp2.net and then to sip:1-408-555-1234@pbx.example.com before being delivered to the pbx. Thanks, Paul From pkyzivat@cisco.com Tue Jan 5 08:40:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C3128C10A for ; Tue, 5 Jan 2010 08:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wqHkej6xUPH for ; Tue, 5 Jan 2010 08:40:24 -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 59F103A692B for ; Tue, 5 Jan 2010 08:40:24 -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: ApoEAKf6QkutJV2a/2dsb2JhbAC/aJRShDAE X-IronPort-AV: E=Sophos;i="4.47,506,1257120000"; d="scan'208";a="78423415" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2010 16:40:22 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o05GeMxO022579; Tue, 5 Jan 2010 16:40:22 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:40:22 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 10:40:21 -0600 Message-ID: <4B436B75.9050005@cisco.com> Date: Tue, 05 Jan 2010 11:40:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2010 16:40:21.0900 (UTC) FILETIME=[C5EC1CC0:01CA8E25] Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:40:25 -0000 Elwell, John wrote: >> I don't want to invoke a provisioning action because one of >> my employees >> is traveling from the Dallas office to the Kansas office for >> two days. >> Based on the SSPs I've worked with, by the time the ticket is closed, >> he'll be back in Dallas anyway. > [JRE] I guess there are two ways to do this temporary move type scenario from PBX1 to PBX2. One is as you suggest, you register the fact with the SSP so that SSP forwards all incoming requests to PBX2 instead of PBX1, until such time as PBX2 de-registers that AOR and PBX1 re-registers it. The other way is for all incoming requests to continue to arrive at PBX1 and for PBX1 to route onwards (within the enterprise infrastructure) to PBX2. This is the way it would work if the source of the request were a local UA on PBX1 - PBX 1 would just route it to PBX2. So given that PBX1 has this capability, why can't it use this for requests arriving from the SSP? The latter assumes the enterprise infrastructure is up to the task of carrying the phone calls between sites. Some enterprises are set up for that, and some are not. Thanks, Paul From adam@nostrum.com Tue Jan 5 08:43:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7D83A682B for ; Tue, 5 Jan 2010 08:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6p1mt79vGmy for ; Tue, 5 Jan 2010 08:43:18 -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 6AD5F3A67E3 for ; Tue, 5 Jan 2010 08:43:17 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o05Gh95r081755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 10:43:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B436C1D.1050002@nostrum.com> Date: Tue, 05 Jan 2010 10:43:09 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Paul Kyzivat References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> <4B436B75.9050005@cisco.com> In-Reply-To: <4B436B75.9050005@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 16:43:19 -0000 On 1/5/10 10:40, Jan 5, Paul Kyzivat wrote: > > > Elwell, John wrote: > >>> I don't want to invoke a provisioning action because one of my >>> employees is traveling from the Dallas office to the Kansas office >>> for two days. Based on the SSPs I've worked with, by the time the >>> ticket is closed, he'll be back in Dallas anyway. >> [JRE] I guess there are two ways to do this temporary move type >> scenario from PBX1 to PBX2. One is as you suggest, you register the >> fact with the SSP so that SSP forwards all incoming requests to PBX2 >> instead of PBX1, until such time as PBX2 de-registers that AOR and >> PBX1 re-registers it. The other way is for all incoming requests to >> continue to arrive at PBX1 and for PBX1 to route onwards (within the >> enterprise infrastructure) to PBX2. This is the way it would work if >> the source of the request were a local UA on PBX1 - PBX 1 would just >> route it to PBX2. So given that PBX1 has this capability, why can't >> it use this for requests arriving from the SSP? > > The latter assumes the enterprise infrastructure is up to the task of > carrying the phone calls between sites. Some enterprises are set up > for that, and some are not. Very true. I certainly wouldn't want to tie up 180 kbps of bandwidth on my T1 hairpinning a call out to another site. That's over 10% of the total link capacity... /a From bernard_aboba@hotmail.com Tue Jan 5 09:02:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D90828C115 for ; Tue, 5 Jan 2010 09:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 g48OHngDoOC0 for ; Tue, 5 Jan 2010 09:02:04 -0800 (PST) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id 6A90B3A67E3 for ; Tue, 5 Jan 2010 09:02:04 -0800 (PST) Received: from BLU137-W17 ([65.55.111.72]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 09:02:03 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f91119cd-aa67-4cb1-9f0c-70c4140d6bc7_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Tue, 5 Jan 2010 09:02:03 -0800 Importance: Normal In-Reply-To: <4B436512.7070309@cisco.com> References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com>,<4B436512.7070309@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2010 17:02:03.0445 (UTC) FILETIME=[CDB41E50:01CA8E28] Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 17:02:05 -0000 --_f91119cd-aa67-4cb1-9f0c-70c4140d6bc7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said: > But=2C is it reasonable to expect a sip request to convey > several hundred AORs? (And what if it becomes several thousand?) > This is out of the scope of what sip requests were designed to handle. >=20 > If that path is taken=2C then next people will be asking to encode those= =20 > more tightly=2C such as by specifying ranges of numbers. But of course=20 > that won't work for non-numeric addresses. It starts to look very ugly. These are two of the issues that Hadriel raises in the draft. =20 Setting aside the precise details of how to go about it=2C I'm wondering whether we can come to any conclusions as to whether solutions to these issues are REQUIRED=2C RECOMMENDED or OPTIONAL. =20 = --_f91119cd-aa67-4cb1-9f0c-70c4140d6bc7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul said:

>=3B But=2C is it reasonable to expect a sip request to= convey
>=3B several hundred AORs? (And what if it becomes several tho= usand?)
>=3B This is out of the scope of what sip requests were design= ed to handle.
>=3B
>=3B If that path is taken=2C then next peopl= e will be asking to encode those
>=3B more tightly=2C such as by spec= ifying ranges of numbers. But of course
>=3B that won't work for non-= numeric addresses. It starts to look very ugly.

These are two of the= issues that Hadriel raises in the draft. =3B =3B

Setting a= side the precise details of how to go about it=2C =3B I'm wondering
= whether we can come to any conclusions as to whether solutions
to these = issues are REQUIRED=2C RECOMMENDED or OPTIONAL. =3B
= --_f91119cd-aa67-4cb1-9f0c-70c4140d6bc7_-- From john.elwell@siemens-enterprise.com Tue Jan 5 10:04:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D9D28C0DC for ; Tue, 5 Jan 2010 10:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 t1TmLo38y1ZQ for ; Tue, 5 Jan 2010 10:04:01 -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 9C12628C13C for ; Tue, 5 Jan 2010 10:04:00 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-444592; Tue, 5 Jan 2010 19:03:58 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id C00081EB828D; Tue, 5 Jan 2010 19:03:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 19:03:58 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 5 Jan 2010 19:03:56 +0100 Thread-Topic: [martini] draft-kaplan-martini-mixing-problems: solution requirements? Thread-Index: AcqOJTcTYkVGgA0STNyXJO4I4kJ/7QAC6Kmg Message-ID: References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> <4B436A83.40305@cisco.com> In-Reply-To: <4B436A83.40305@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: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:04:02 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 05 January 2010 16:36 > To: Elwell, John > Cc: Adam Roach; Bernard Aboba; martini@ietf.org > Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > solution requirements? >=20 >=20 >=20 > Elwell, John wrote: >=20 > >> I don't think that works the way you think it does. In=20 > your example,=20 > >> what do you get when you run "pbx.example.com" through 3263=20 > >> resolution=20 > >> rules? Does it point to the SSP or the PBX? If it points=20 > to the PBX,=20 > >> then the justification described by=20 > >> draft-kaplan-martini-shaken-implicit-registrations goes away. That=20 > >> particular PBX is not a candidate for MARTINI procedures. > > [JRE] Internally the PBX would be able to route on=20 > pbx.example.com (it would treat it as its own domain, as it=20 > would if its own IP address were in the domain part). This=20 > does not necessarily mean that pbx.example.com is published=20 > to the whole world so that they can get there without using=20 > MARTINI procedures. For most purposes today, E.164 numbers=20 > are used, so a request could start off as addressed to=20 > sip:+123456789@ssp.example.net (or tel:+12345679, which would=20 > get resolved to sip:+123456789@ssp.example.net). The SSP=20 > (ssp.example.net) would use MARTINI procedures to get it to=20 > the PBX. For delivery to the PBX you need something different=20 > in the domain part (e.g., IP address or pbx.example.com) so=20 > that, on receipt, the PBX doesn't simply route it back to the SSP. >=20 > I don't buy that logic. >=20 > If you want requests to pbx.example.com to go through the martini=20 > processes, then responsibility for that domain needs to=20 > reside with the=20 > SSP. >=20 > What you describe amounts to having a split-DNS, where the=20 > resolution of=20 > that domain name gets a different answer inside the=20 > enterprise than it=20 > does outside. I don't find that an appealing direction to go. >=20 > If you want the pbx to have its own domain name, then it=20 > needs to be a=20 > different one from the one used to reach its numbers at the SSP. [JRE] Yes, and that is what I show in my example above. >=20 > When routing on numbers in the SSP world the domain names are=20 > constantly=20 > changing in any case. It seems plausible to me that 1-408-555-1234 is=20 > initially addressed to sip:1-408-555-1234@ssp1.net, gets routed by=20 > ssp1.net to ssp2.net and in the process gets rewritten as=20 > sip:1-408-555-1234@ssp2.net, then mapped by ssp2 to=20 > sip:1-408-555-1234@pbx.example.ssp2.net and then to=20 > sip:1-408-555-1234@pbx.example.com before being delivered to the pbx. [JRE] I agree. And if a local UA on the PBX issues a request to sip:1-408-5= 55-1234@pbx.example.com the PBX would resolve it locally. John >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Tue Jan 5 10:07:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B0D28C0DC for ; Tue, 5 Jan 2010 10:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+k-mL4jHtFL for ; Tue, 5 Jan 2010 10:07:10 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5C91728C149 for ; Tue, 5 Jan 2010 10:07:10 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-444518; Tue, 5 Jan 2010 19:07:08 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BE0DA23F0271; Tue, 5 Jan 2010 19:07:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 5 Jan 2010 19:07:08 +0100 From: "Elwell, John" To: Adam Roach , Paul Kyzivat Date: Tue, 5 Jan 2010 19:07:06 +0100 Thread-Topic: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOJjAbL8Np0oWiTKit8fz3hdvqjQAC47iw Message-ID: References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> <4B436B75.9050005@cisco.com> <4B436C1D.1050002@nostrum.com> In-Reply-To: <4B436C1D.1050002@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:07:11 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 05 January 2010 16:43 > To: Paul Kyzivat > Cc: Elwell, John; Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Who designates AORs? (was Re:=20 > draft-kaplan-martini-mixing-problems: solution requirements?) >=20 > On 1/5/10 10:40, Jan 5, Paul Kyzivat wrote: > > > > > > Elwell, John wrote: > > > >>> I don't want to invoke a provisioning action because one of my=20 > >>> employees is traveling from the Dallas office to the=20 > Kansas office=20 > >>> for two days. Based on the SSPs I've worked with, by the time the=20 > >>> ticket is closed, he'll be back in Dallas anyway. > >> [JRE] I guess there are two ways to do this temporary move type=20 > >> scenario from PBX1 to PBX2. One is as you suggest, you=20 > register the=20 > >> fact with the SSP so that SSP forwards all incoming=20 > requests to PBX2=20 > >> instead of PBX1, until such time as PBX2 de-registers that AOR and=20 > >> PBX1 re-registers it. The other way is for all incoming=20 > requests to=20 > >> continue to arrive at PBX1 and for PBX1 to route onwards=20 > (within the=20 > >> enterprise infrastructure) to PBX2. This is the way it=20 > would work if=20 > >> the source of the request were a local UA on PBX1 - PBX 1=20 > would just=20 > >> route it to PBX2. So given that PBX1 has this capability,=20 > why can't=20 > >> it use this for requests arriving from the SSP? > > > > The latter assumes the enterprise infrastructure is up to=20 > the task of=20 > > carrying the phone calls between sites. Some enterprises are set up=20 > > for that, and some are not. >=20 > Very true. I certainly wouldn't want to tie up 180 kbps of=20 > bandwidth on=20 > my T1 hairpinning a call out to another site. That's over 10% of the=20 > total link capacity... [JRE] Of course not, but if you can reach the other site only via the SSP, = then redirection might be another possibility. John >=20 > /a > = From pkyzivat@cisco.com Tue Jan 5 10:17:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913AE28C13C for ; Tue, 5 Jan 2010 10:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-diiIc2j2ZU for ; Tue, 5 Jan 2010 10:17:56 -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 4107128C107 for ; Tue, 5 Jan 2010 10:17:56 -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: ApoEAOsQQ0utJV2b/2dsb2JhbAC/O4kNCYs9gkeBaQQ X-IronPort-AV: E=Sophos;i="4.47,507,1257120000"; d="scan'208";a="78444166" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2010 18:17:54 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o05IHseI013699; Tue, 5 Jan 2010 18:17:54 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 12:17:54 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 12:17:53 -0600 Message-ID: <4B438252.6020606@cisco.com> Date: Tue, 05 Jan 2010 13:17:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> <4B436A83.40305@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2010 18:17:53.0705 (UTC) FILETIME=[65DEB190:01CA8E33] Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 18:17:57 -0000 at end... Elwell, John wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 05 January 2010 16:36 >> To: Elwell, John >> Cc: Adam Roach; Bernard Aboba; martini@ietf.org >> Subject: Re: [martini] draft-kaplan-martini-mixing-problems: >> solution requirements? >> >> >> >> Elwell, John wrote: >> >>>> I don't think that works the way you think it does. In >> your example, >>>> what do you get when you run "pbx.example.com" through 3263 >>>> resolution >>>> rules? Does it point to the SSP or the PBX? If it points >> to the PBX, >>>> then the justification described by >>>> draft-kaplan-martini-shaken-implicit-registrations goes away. That >>>> particular PBX is not a candidate for MARTINI procedures. >>> [JRE] Internally the PBX would be able to route on >> pbx.example.com (it would treat it as its own domain, as it >> would if its own IP address were in the domain part). This >> does not necessarily mean that pbx.example.com is published >> to the whole world so that they can get there without using >> MARTINI procedures. For most purposes today, E.164 numbers >> are used, so a request could start off as addressed to >> sip:+123456789@ssp.example.net (or tel:+12345679, which would >> get resolved to sip:+123456789@ssp.example.net). The SSP >> (ssp.example.net) would use MARTINI procedures to get it to >> the PBX. For delivery to the PBX you need something different >> in the domain part (e.g., IP address or pbx.example.com) so >> that, on receipt, the PBX doesn't simply route it back to the SSP. >> >> I don't buy that logic. >> >> If you want requests to pbx.example.com to go through the martini >> processes, then responsibility for that domain needs to >> reside with the >> SSP. >> >> What you describe amounts to having a split-DNS, where the >> resolution of >> that domain name gets a different answer inside the >> enterprise than it >> does outside. I don't find that an appealing direction to go. >> >> If you want the pbx to have its own domain name, then it >> needs to be a >> different one from the one used to reach its numbers at the SSP. > [JRE] Yes, and that is what I show in my example above. > >> When routing on numbers in the SSP world the domain names are >> constantly >> changing in any case. It seems plausible to me that 1-408-555-1234 is >> initially addressed to sip:1-408-555-1234@ssp1.net, gets routed by >> ssp1.net to ssp2.net and in the process gets rewritten as >> sip:1-408-555-1234@ssp2.net, then mapped by ssp2 to >> sip:1-408-555-1234@pbx.example.ssp2.net and then to >> sip:1-408-555-1234@pbx.example.com before being delivered to the pbx. > [JRE] I agree. And if a local UA on the PBX issues a request to sip:1-408-555-1234@pbx.example.com the PBX would resolve it locally. So then the question remains: if someone outside the enterprise, and outside the SSP, sends a sip request to sip:1-408-555-1234@pbx.example.com, what happens? I presume that in that case the ssp would not be involved. Then one of two things will happen: - there is no global DNS mapping for this address, so the request fails - there is a global DNS mapping for this address, to the pbx, so the request succeeds. In this case there was no need to use the registration mechanism. Thanks, Paul From john.elwell@siemens-enterprise.com Tue Jan 5 12:17:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876E03A689F for ; Tue, 5 Jan 2010 12:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xgiCQPTo67o for ; Tue, 5 Jan 2010 12:17:14 -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 BEBED3A684A for ; Tue, 5 Jan 2010 12:17:13 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-445616; Tue, 5 Jan 2010 21:17:11 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 749E523F026F; Tue, 5 Jan 2010 21:17:11 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 5 Jan 2010 21:17:11 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 5 Jan 2010 21:17:09 +0100 Thread-Topic: [martini] draft-kaplan-martini-mixing-problems: solution requirements? Thread-Index: AcqOM2cGl+vvZKb1RditHROrjABiCQAD+7MQ Message-ID: References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> <4B436A83.40305@cisco.com> <4B438252.6020606@cisco.com> In-Reply-To: <4B438252.6020606@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: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:17:16 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 05 January 2010 18:18 > To: Elwell, John > Cc: Adam Roach; Bernard Aboba; martini@ietf.org > Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > solution requirements? >=20 > at end... >=20 > Elwell, John wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > >> Sent: 05 January 2010 16:36 > >> To: Elwell, John > >> Cc: Adam Roach; Bernard Aboba; martini@ietf.org > >> Subject: Re: [martini] draft-kaplan-martini-mixing-problems:=20 > >> solution requirements? > >> > >> > >> > >> Elwell, John wrote: > >> > >>>> I don't think that works the way you think it does. In=20 > >> your example,=20 > >>>> what do you get when you run "pbx.example.com" through 3263=20 > >>>> resolution=20 > >>>> rules? Does it point to the SSP or the PBX? If it points=20 > >> to the PBX,=20 > >>>> then the justification described by=20 > >>>> draft-kaplan-martini-shaken-implicit-registrations goes=20 > away. That=20 > >>>> particular PBX is not a candidate for MARTINI procedures. > >>> [JRE] Internally the PBX would be able to route on=20 > >> pbx.example.com (it would treat it as its own domain, as it=20 > >> would if its own IP address were in the domain part). This=20 > >> does not necessarily mean that pbx.example.com is published=20 > >> to the whole world so that they can get there without using=20 > >> MARTINI procedures. For most purposes today, E.164 numbers=20 > >> are used, so a request could start off as addressed to=20 > >> sip:+123456789@ssp.example.net (or tel:+12345679, which would=20 > >> get resolved to sip:+123456789@ssp.example.net). The SSP=20 > >> (ssp.example.net) would use MARTINI procedures to get it to=20 > >> the PBX. For delivery to the PBX you need something different=20 > >> in the domain part (e.g., IP address or pbx.example.com) so=20 > >> that, on receipt, the PBX doesn't simply route it back to the SSP. > >> > >> I don't buy that logic. > >> > >> If you want requests to pbx.example.com to go through the martini=20 > >> processes, then responsibility for that domain needs to=20 > >> reside with the=20 > >> SSP. > >> > >> What you describe amounts to having a split-DNS, where the=20 > >> resolution of=20 > >> that domain name gets a different answer inside the=20 > >> enterprise than it=20 > >> does outside. I don't find that an appealing direction to go. > >> > >> If you want the pbx to have its own domain name, then it=20 > >> needs to be a=20 > >> different one from the one used to reach its numbers at the SSP. > > [JRE] Yes, and that is what I show in my example above. > >=20 > >> When routing on numbers in the SSP world the domain names are=20 > >> constantly=20 > >> changing in any case. It seems plausible to me that=20 > 1-408-555-1234 is=20 > >> initially addressed to sip:1-408-555-1234@ssp1.net, gets routed by=20 > >> ssp1.net to ssp2.net and in the process gets rewritten as=20 > >> sip:1-408-555-1234@ssp2.net, then mapped by ssp2 to=20 > >> sip:1-408-555-1234@pbx.example.ssp2.net and then to=20 > >> sip:1-408-555-1234@pbx.example.com before being delivered=20 > to the pbx. > > [JRE] I agree. And if a local UA on the PBX issues a=20 > request to sip:1-408-555-1234@pbx.example.com the PBX would=20 > resolve it locally. >=20 > So then the question remains: if someone outside the enterprise, and=20 > outside the SSP, sends a sip request to=20 > sip:1-408-555-1234@pbx.example.com, what happens? >=20 > I presume that in that case the ssp would not be involved. > Then one of two things will happen: > - there is no global DNS mapping for this address, so the > request fails > - there is a global DNS mapping for this address, to the > pbx, so the request succeeds. In this case there was no > need to use the registration mechanism. [JRE] Yes, it would fail - you would need to use one of the other forms abo= ve, so that is what you would need to publish publicly (e.g., on your busin= ess card). The alternatives are to use one of the above forms (e.g., sip:1-= 408-555-1234@ssp2.net) all the time, even internally within the PBX, but th= en we would have a split responsibility for that domain. John From pkyzivat@cisco.com Tue Jan 5 12:34:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDD13A68CB for ; Tue, 5 Jan 2010 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsJCYw1tWcZx for ; Tue, 5 Jan 2010 12:34:19 -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 A7E5B3A6767 for ; Tue, 5 Jan 2010 12:34:19 -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: ApoEAH8xQ0utJV2b/2dsb2JhbAC/E4kNCYs1gkeBaQQ X-IronPort-AV: E=Sophos;i="4.49,224,1262563200"; d="scan'208";a="78365241" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2010 20:34:17 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o05KYHQK004815; Tue, 5 Jan 2010 20:34:17 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 14:34:17 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 14:34:17 -0600 Message-ID: <4B43A235.9070904@cisco.com> Date: Tue, 05 Jan 2010 15:33:57 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B394119.4040502@nostrum.com> <4B4354AF.8060500@nostrum.com> <4B436A83.40305@cisco.com> <4B438252.6020606@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jan 2010 20:34:17.0333 (UTC) FILETIME=[73B13A50:01CA8E46] Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] draft-kaplan-martini-mixing-problems: solution requirements? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 20:34:21 -0000 I agree that the approach below can work. IIRC, somebody (was it Cullen) had an aversion to using "DNS" names that have no registered address. Thanks, Paul Elwell, John wrote: >>>> What you describe amounts to having a split-DNS, where the >>>> resolution of >>>> that domain name gets a different answer inside the >>>> enterprise than it >>>> does outside. I don't find that an appealing direction to go. >>>> >>>> If you want the pbx to have its own domain name, then it >>>> needs to be a >>>> different one from the one used to reach its numbers at the SSP. >>> [JRE] Yes, and that is what I show in my example above. >>> >>>> When routing on numbers in the SSP world the domain names are >>>> constantly >>>> changing in any case. It seems plausible to me that >> 1-408-555-1234 is >>>> initially addressed to sip:1-408-555-1234@ssp1.net, gets routed by >>>> ssp1.net to ssp2.net and in the process gets rewritten as >>>> sip:1-408-555-1234@ssp2.net, then mapped by ssp2 to >>>> sip:1-408-555-1234@pbx.example.ssp2.net and then to >>>> sip:1-408-555-1234@pbx.example.com before being delivered >> to the pbx. >>> [JRE] I agree. And if a local UA on the PBX issues a >> request to sip:1-408-555-1234@pbx.example.com the PBX would >> resolve it locally. >> >> So then the question remains: if someone outside the enterprise, and >> outside the SSP, sends a sip request to >> sip:1-408-555-1234@pbx.example.com, what happens? >> >> I presume that in that case the ssp would not be involved. >> Then one of two things will happen: >> - there is no global DNS mapping for this address, so the >> request fails >> - there is a global DNS mapping for this address, to the >> pbx, so the request succeeds. In this case there was no >> need to use the registration mechanism. > [JRE] Yes, it would fail - you would need to use one of the other forms above, so that is what you would need to publish publicly (e.g., on your business card). The alternatives are to use one of the above forms (e.g., sip:1-408-555-1234@ssp2.net) all the time, even internally within the PBX, but then we would have a split responsibility for that domain. > > John > From bernard_aboba@hotmail.com Tue Jan 5 22:08:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067AC3A67A4 for ; Tue, 5 Jan 2010 22:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.327 X-Spam-Level: X-Spam-Status: No, score=-1.327 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_20=-0.74, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMf99opa6e5g for ; Tue, 5 Jan 2010 22:08:21 -0800 (PST) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by core3.amsl.com (Postfix) with ESMTP id 20E833A63EB for ; Tue, 5 Jan 2010 22:08:21 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.71]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jan 2010 22:08:18 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: , Date: Tue, 5 Jan 2010 22:08:17 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqDSTBDXT4DjBfyTk6dKLohaQFE6ALTXK5Q Content-Language: en-us X-OriginalArrivalTime: 06 Jan 2010 06:08:18.0701 (UTC) FILETIME=[A458EBD0:01CA8E96] Subject: [martini] Update: MARTINI Virtual Interim, January 7, 2010 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 06:08:22 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org ATTENDEE;CN='jon.peterson@neustar.biz';RSVP=TRUE:mailto:jon.peterson@neusta r.biz CLASS:PUBLIC CREATED:20100106T060816Z DESCRIPTION:When: Thursday\, January 07\, 2010 11:00 AM-1:30 PM (UTC-08:00) Pacific Time (US & Canada).\nWhere: https://workgreen.webex.com/workgreen /j.php?ED=131012752&UID=1110677752&PW=NNjRjYjAzNDVj&RT=MiM3 \n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~* ~*~*~*~*~*~*~*~*\n\nIETF Secretariat invites you to attend this online mee ting. \n\nTopic: Martini WG Virtual Meeting \nDate: Thursday\, January 7\, 2010 \nTime: 11:00 am\, Pacific Time (GMT-08:00) \nMeeting Number: 961 98 2 327 \nMeeting Password: martini \n\n\n---------------------------------- --------------------- \nTo join the online meeting (Now from iPhones too!) \n------------------------------------------------------- \n1. Go to http s://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=1110677752&PW=NNj RjYjAzNDVj&RT=MiM3 \n2. Enter your name and email address. \n3. Enter the meeting password: martini \n4. Click "Join Now". \n\nTo view in other time zones or languages\, please click the link: \nhttps://workgreen.webex.com /workgreen/j.php?ED=131012752&UID=1110677752&PW=NNjRjYjAzNDVj&ORT=MiM3 \n\ n------------------------------------------------------- \nTo join the aud io conference only \n----------------------------------------------------- -- \nTo receive a call back\, provide your phone number when you join the meeting\, or call the number below and enter the access code. \nCall-in to ll number (US/Canada): 1-408-792-6300 \nGlobal call-in numbers: https://wo rkgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=131012752&t ollFree=0 \n\nAccess code:961 982 327 \n\n-------------------------------- ----------------------- \nFor assistance \n------------------------------- ------------------------ \n1. Go to https://workgreen.webex.com/workgreen/ mc \n2. On the left navigation bar\, click "Support". \n\nYou can contact me at: \namorris@amsl.com \n1-510-492-4081 \n\nTo add this meeting to your calendar program (for example Microsoft Outlook)\, click this link: \nhtt ps://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=1110677752&ICS=M I&LD=1&RD=2&ST=1&SHA2=S077yUqV0ofHSq-PMxL5msi2bEZ05DYLHo/Yq6aLYEQ=&RT=MiM3 \n\nThe playback of UCF (Universal Communications Format) rich media file s requires appropriate players. To view this type of rich media files in t he meeting\, please check whether you have the players installed on your c omputer by going to https://workgreen.webex.com/workgreen/systemdiagnosis. php \n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfr eetrial \n\nhttp://www.webex.com \n\n\n\nIMPORTANT NOTICE: This WebEx serv ice includes a feature that allows audio and any documents and other mater ials exchanged or viewed during the session to be recorded. By joining thi s session\, you automatically consent to such recordings. If you do not co nsent to the recording\, do not join the session. \n\nMARTINI Virtual Inte rim\nJanuary 7\, 2010\n11 AM – 1:00 PM Pacific Time\n\nConferencing Deta ils: \n\nSlide Presentations: http://www.drizzle.com/~aboba/MARTINI/\nJab ber room: martini at jabber.ietf.org (Please join)\nDial in Audioconferen ce and WebEx details: \nhttp://www.ietf.org/mail-archive/web/martini/curr ent/msg00029.html\n\nAgenda\n\n11 AM - 11:10 AM PT: Preliminaries\n C onference issues/debugging\n Agenda bash\n\nProblem Statement & Existi ng Deployed Solutions (30 minutes)\n\n11:10 AM - 11:40 AM PT SIP IP-PBX R egistration Problems\, Hadriel Kaplan (30 minutes)\nhttp://www.ietf.org/id /draft-kaplan-martini-mixing-problems-00.txt\n\nPotential Solutions (45 mi nutes)\n\n11:40 AM - 12:10 PM PT SIP Implicit Registrations\, Presenter: Hadriel Kaplan (30 minutes)\nhttp://www.ietf.org/id/draft-kaplan-martini-s haken-implicit-registrations-00.txt\n\n12:10 PM - 12:25 PM PT Domain Regis tration\, Hadriel Kaplan (15 minutes)\nhttp://www.ietf.org/id/draft-kaplan -martini-stirred-domain-registration-00.txt \n\nWrap-up (35 minutes)\n\n12 :25 PM - 12:40 PM PT Discussion: Participants (15 minutes)\n12:40 PM - 1 2:55 PM PT Hums: WG Chairs (15 minutes)\n12:55 PM - 1:00 PM PT Next St eps: WG Chairs & ADs (5 minutes)\n\n DTEND:20100107T213000Z DTSTAMP:20100106T060816Z DTSTART:20100107T190000Z LAST-MODIFIED:20100106T060816Z LOCATION:https://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=11106 77752&PW=NNjRjYjAzNDVj&RT=MiM3 ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:2 SUMMARY;LANGUAGE=en-us:Update: MARTINI Virtual Interim\, January 7\, 2010 TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000408720220683CA01000000000000000 010000000DA6110A441C06645A498881E714794AD X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Thursday\, January 07\, 2010 11:00 AM-1:30 PM (UTC-08:00) Pacific Time (US &\; Can ada).

\n\n

Where: https://workgreen.webex.com/workgreen/j.php?ED=131012752&U ID=1110677752&PW=NNjRjYjAzNDVj&RT=MiM3

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~ *~*~*~*

\n\n

IETF Secretariat invites you to attend this online meeting.
\n
\nTopic: Martini WG Virtual Meeting
\nDate: T hursday\, January 7\, 2010
\nTime: 11:00 am\, Pacific Time (GMT-08:00)< BR>\nMeeting Number: 961 982 327
\nMeeting Password: martini
\n
\ n
\n-------------------------------------------------------
\nTo joi n the online meeting (Now from iPhones too!)
\n------------------------ -------------------------------
\n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131012752&\;UID=11106 77752&\;PW=NNjRjYjAzNDVj&\;RT=MiM3
\n2. Enter your name and email address.
\n3. Enter the meeting password: martini
\n4. Click "\;Join Now"\;.
\n
\ nTo view in other time zones or languages\, please click the link:
\nhttps://workgreen.webex.com/workgreen/j.php? ED=131012752&\;UID=1110677752&\;PW=NNjRjYjAzNDVj&\;ORT=MiM3
\n
\n---------------------- ---------------------------------
\nTo join the audio conference only\n-------------------------------------------------------
\nTo receiv e a call back\, provide your phone number when you join the meeting\, or c all the number below and enter the access code.
\nCall-in toll number ( US/Canada): 1-408-792-6300
\nGlobal call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC &\;ED=131012752&\;tollFree=0
\n
\nAccess code:961 982 327
\n
\n--------------------- ----------------------------------
\nFor assistance
\n-------------- -----------------------------------------
\n1. Go to < SPAN LANG="en-us">https://workgreen.webex.com/workgreen/mc
\n2. On the left navigation bar\, click &q uot\;Support"\;.
\n
\nYou can contact me at:
\n amorris@amsl.com
\n1-5 10-492-4081
\n
\nTo add this meeting to your calendar program (for e xample Microsoft Outlook)\, click this link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=131012752&\;UID= 1110677752&\;ICS=MI&\;LD=1&\;RD=2&\;ST=1&\;SHA2=S077yUqV0of HSq-PMxL5msi2bEZ05DYLHo/Yq6aLYEQ=&\;RT=MiM3
\n
\nThe playback of UCF (Universal Communication s Format) rich media files requires appropriate players. To view this type of rich media files in the meeting\, please check whether you have the pl ayers installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosi s.php
\n
\nSign up for a free trial of WebEx
\nhttp://www.webe x.com/go/mcemfreetrial
\n
\nhttp://www.webex.com
\n
\n
\n
\nIMPORTANT NOTICE: This WebEx service i ncludes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this ses sion\, you automatically consent to such recordings. If you do not consent to the recording\, do not join the session.

\n\n

\n\n

MARTINI Virtual Interim

\n\n

January 7\, 2010

\n\n

11 AM – 1:00 PM Pacific Time

\n\n

Conferencing Details:

\n\n

Slide Presentations:  http ://www.drizzle.com/~aboba/MARTINI/

\n\n

Ja bber room:  martini at jabber.ietf.org (Please join)

\n\n

Dial in Audioconference and WebEx details: 

\n\n

http://www.ietf.org/mail-archive/web/martini/current/m sg00029.html

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

     Conference issues/debugging

\n\n

     Agenda bash

\n \n

Problem Statement &\; Existing Deployed Solutions (30 minutes)

\n\n

11:10 AM - 11:40 AM  PT SIP IP-PBX Registration Problems\, Hadriel Kaplan (30 m inutes)

\n\n

http://www.ietf.org/id/draft-kaplan-martin i-mixing-problems-00.txt

\n\n

Potential So lutions (45 minutes)

\n\n

11:40 AM - 12:10 PM PT  SIP Implicit Registrations\, Presenter: Hadriel Kaplan (30 minutes)

\n\n

http://www.ietf.org/id/dra ft-kaplan-martini-shaken-implicit-registrations-00.txt

\n\n

< SPAN LANG="en-us">12:10 PM - 12:25 PM PT Domain Registration\, Hadriel Kap lan (15 minutes)

\n\n

http://www.ietf.org/i d/draft-kaplan-martini-stirred-domain-registration-00.txt

\n\n

Wrap-up (35 minutes)

\n\n

12:25 PM - 12:40 PM PT  Discussion:  Participants (15 minut es)

\n\n

12:40 PM - 12:55 PM PT  H ums:  WG Chairs (15 minutes)

\n\n

12:55 PM - 1:00 PM PT   Next Steps:  WG Chairs &\; ADs (5 minutes)

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:1 X-MS-OLK-APPTSEQTIME:20091222T205851Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From adam@nostrum.com Tue Jan 5 22:14:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F43B3A67A4 for ; Tue, 5 Jan 2010 22:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 C5NY0VPBB2sA for ; Tue, 5 Jan 2010 22:14:13 -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 9951328C0E3 for ; Tue, 5 Jan 2010 22:14:11 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o066E3iW080753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 00:14:03 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B442A2B.3010407@nostrum.com> Date: Wed, 06 Jan 2010 00:14:03 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000904010905070709090003" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Slides and additional Agenda items X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 06:14:15 -0000 This is a multi-part message in MIME format. --------------000904010905070709090003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As a quick heads-up: I don't know if it's going to have enough review time to legitimately be on the agenda, but I do plan to throw a draft onto the list early tomorrow to provide some ideas around how things can be done in ways that completely obviate the problems existing solutions have. The draft is only about 14 pages long, including boilerplate. Feel free to add an agenda slot -- or don't -- as you see fit. The draft will be titled "draft-roach-martini-up-00." /a On 1/5/10 08:01, Jan 5, Bernard Aboba wrote: > > If you are intending to present at the Virtual Interim, we would like > to get your slides no later than Wednesday, January 6, 2010 in order > to make sure that they are available online. > > Also, if you would like agenda time, please let myself or Spencer know > ASAP. > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --------------000904010905070709090003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As a quick heads-up:

I don't know if it's going to have enough review time to legitimately be on the agenda, but I do plan to throw a draft onto the list early tomorrow to provide some ideas around how things can be done in ways that completely obviate the problems existing solutions have. The draft is only about 14 pages long, including boilerplate.

Feel free to add an agenda slot -- or don't -- as you see fit. The draft will be titled "draft-roach-martini-up-00."

/a

On 1/5/10 08:01, Jan 5, Bernard Aboba wrote:

If you are intending to present at the Virtual Interim, we would like to get your slides no later than Wednesday, January 6, 2010 in order to make sure that they are available online. 

 

Also, if you would like agenda time, please let myself or Spencer know ASAP.  


_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini
   
--------------000904010905070709090003-- From drage@alcatel-lucent.com Wed Jan 6 06:50:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC073A6849 for ; Wed, 6 Jan 2010 06:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18dLtpGjPpJ5 for ; Wed, 6 Jan 2010 06:50:40 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 7D9753A677C for ; Wed, 6 Jan 2010 06:50:38 -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 o06Eoap5020540 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 6 Jan 2010 15:50:36 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 6 Jan 2010 15:50:36 +0100 From: "DRAGE, Keith (Keith)" To: "martini@ietf.org" Date: Wed, 6 Jan 2010 15:50:34 +0100 Thread-Topic: Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO35nAG4kI9e3ORH2eKoHrt/5ACA== 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-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 14:50:41 -0000 I've just starting trying to work my way through these drafts. Firstly can I point out that we have elements in the set of drafts of tryin= g to standardise beyond the event, where is some cases that event was 3GPP = release 5 (which was frozen in 2002). So please remember that IETF may well= not be the prime place of specification of these issues. Now to the draft draft-kaplan-martini-mixing-problems-00. 1) Additional indicator -------------------------- draft-kaplan-martini-mixing-problems-00 seems to be arguing for an indicato= r, but I am left in doubt as to what that indicator is for. While I am not = opposed to the creation of new indicators, any indicator needs clear requir= ements, and a clear understanding of why it is needed. Is it: A) to indicate that implicit registration is being used. But implicit regis= tration has existed for all IMS usages since day one. It is reflected in th= e requirements in RFC 4083 as follows: 4.10.2.2. Registration of Public User IDs It must be possible to register globally (i.e., through one single UA request) a user that has more than one public identity that belongs to the same user profile, via a mechanism within the IMS. In this case, the user will be registered with all the public identities associated to a user profile. We believe this requirement may be accomplished by external procedures. For example, the user's profile may contain a list of alias identities that the registrar considers active if the primary identity is registered. The user may get informed of the automatically registered public user IDs by subscribing to its own registration state. Implicit registration is therefore not specific to PBX usage, and is normal= for IMS usage. B) to indicate that "loose routeing" is being used. Note that this is poor = naming because it is not really that. Secondly the usage of this is intende= d to be standard for all subscription based approachs. What in essence TISP= AN and 3GPP were trying to do is provide compatible usages in incoming requ= ests for normal peering type connections (where the PBX is routed to using = standard DNS mechanisms), and this registration based approach. Thus the so= lution adopted for IMS treates the attached PBX as if calls were being rout= ed to it using a standard SIP routeing proxy, and the registration mechanis= m is an adjunct to essentially set up the pseudo DNS to drive it. On this b= asis I would argue this is what PBXs based on SIP networks should expect, a= nd the REGISTER is an add on to the standard SIP interconnect at the interf= ace itself, in order to kick the IMS into doing the DNS type job. As such t= he indicator should not be added for this function, because it would also h= ave to be added for any peering based approach as well. Rather, it is the S= IP location server functionality that is the exception, and therefore an in= dicator should be added that the Request-URI has been modified as a result = of location server. This of course will impact all SIP UAs that are out the= re in the field. I would also note that any SBC in the IMS environment has to follow the IMS= rules. IMS will not support the generation of indicators merely to allow t= he insertion of IMS non-compliant devices in the IMS environment. Some of t= he behaviour being discussed in this draft for edge proxies is not IMS comp= liant. 2) Handling of P-Associated-URI ---------------------------------- The document talks about the PBX learning about the implicit registration u= sing the P-Associated-URI, but does not actually say what the requirement f= rom the PBX side is. By default (i.e. because it is there in release 5) the= re are two mechanisms provided in IMS. A) The P-Associated-URI mechanism. This will tell you the URIs that were re= gistered as a result of the usage of the REGISTER method.=20 B) Subscription to the reg event package.=20 It is only the latter that will inform a connected device about the actual = state of registrations on a continuous basis. Note that IMS can remove regi= strations for various reasons (e.g. prepay account is empty). In the absenc= e of requirements does the PBX need either mechanism. It cannot turn off A)= , but it can certainly ignore the information as it should do as UA functio= nality on any unrecognised header. On this basis, it just assumed that the = implicit registration it asked for is granted. Note that IMS does use the reg event package to indicate essentially to the= UA that authentication has been removed (and all the registrations have be= en removed because IMS associates registration with authentication). Essent= ially in this state on IMS, the attached device can do nothing except REGIS= TER, and therefore there are other indicators that this has occurred. 3) Trust domains ------------------- I don't think you are going to solve this issue. You will only solve it by rewriting RFC 3324 and RFC 3325. 4) Wildcarding ----------------- I believe this is something that IETF can usefully extend to tel-URIs. It i= s a powerful and efficient mechanism for defining a range of identifiers, a= nd works equally for tel URIs and SIP URIs. Its usage is an advantage and n= ot a hindrance. Conclusion ---------- I do not think this document adequately addresses a set of requirements, an= d I suspect a set of clearly stated requirements do need to be put in place= before further significant further work is performed. regards Keith= From david.middleton@nsn.com Wed Jan 6 07:51:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55D03A68C7 for ; Wed, 6 Jan 2010 07:51:07 -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 p8+ulsItopT6 for ; Wed, 6 Jan 2010 07:51:07 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id ADDB03A6812 for ; Wed, 6 Jan 2010 07:51:06 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o06Fp2XO031444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Jan 2010 16:51:02 +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 o06Fp26i022464 for ; Wed, 6 Jan 2010 16:51:02 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 16:51:02 +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, 6 Jan 2010 09:50:07 -0600 Message-ID: <159B27ECF9D16E40BD7ABD5778522B0103B7567E@USCHEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOJjAbL8Np0oWiTKit8fz3hdvqjQAC47iwAC1FcVA= References: <4B394119.4040502@nostrum.com><4B434FA1.40300@nostrum.com><4B436B75.9050005@cisco.com> <4B436C1D.1050002@nostrum.com> From: "Middleton, David (NSN - US/Boca Raton)" To: X-OriginalArrivalTime: 06 Jan 2010 15:51:02.0806 (UTC) FILETIME=[0C93F360:01CA8EE8] Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 15:51:07 -0000 If/when the capability to standardize the sort of portability Adam mentioned is done, it should also consider the case of a teleworker using a client that registers directly with the SSP. This aspect helps make a case for addressing this form of portability separately as opposed to encumbering the basic reachability solution. For clarification, the teleworker case that I am referring to is where the teleworker is also a PBX user. Requests would be forked to both the PBX and the teleworker if both are registered. This could be implemented without knowing if the teleworker has a client active behind the PBX but if we head down the path of the SSP knowing the identities behind the PBX, the call should only be forked when the user is available. This very much complicates the feature handling at the IP PBX since the call may not be offered to it. The user could have IP PBX-hosted voice mail or other features like call forwarding that would not be invoked if the call is not routed through the IP PBX. To be clear, my position on this is that it should be considered out-of-scope of the MARTINI WG. David From adam@nostrum.com Wed Jan 6 08:04:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8649C3A68C7 for ; Wed, 6 Jan 2010 08:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 A1eGQ1N0sk67 for ; Wed, 6 Jan 2010 08:04:28 -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 0EA383A6840 for ; Wed, 6 Jan 2010 08:04:27 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o06G4P5P027947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jan 2010 10:04:25 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B44B489.6080708@nostrum.com> Date: Wed, 06 Jan 2010 10:04:25 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: martini@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:04:28 -0000 I have put together a draft that demonstrates several mechanisms that can be used to achieve MARTINI's goals while avoiding the pitfalls that occur with some of the currently deployed mechanisms and proposals. There is still some room for additional fleshing out and other improvements, but the current document contains enough information to convey the basic ideas, and demonstrate feasibility of the proposed mechanisms: http://www.ietf.org/id/draft-roach-martini-up-00.txt /a From bernard_aboba@hotmail.com Wed Jan 6 08:16:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69003A6896 for ; Wed, 6 Jan 2010 08:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_20=-0.74, 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 bn75trvXRLSH for ; Wed, 6 Jan 2010 08:16:50 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 9D0503A67AE for ; Wed, 6 Jan 2010 08:16:50 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 08:16:49 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 6 Jan 2010 08:17:16 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0210_01CA8EA8.A952DB70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqOljeaegsNu+x0SvOvqR19RXBY/QAVBBrA Content-Language: en-us X-OriginalArrivalTime: 06 Jan 2010 16:16:49.0916 (UTC) FILETIME=[A6BA33C0:01CA8EEB] Subject: [martini] MARTINI Virtual Interim Agenda X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:16:54 -0000 ------=_NextPart_000_0210_01CA8EA8.A952DB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim January 7, 2010 11 AM - 1:00 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00029.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Problem Statement & Existing Deployed Solutions (30 minutes) 11:10 AM - 11:40 AM PT SIP IP-PBX Registration Problems, Hadriel Kaplan (30 minutes) http://www.ietf.org/id/draft-kaplan-martini-mixing-problems-00.txt Potential Solutions (50 minutes) 11:40 AM - 12:00 PM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (20 minutes) http://www.ietf.org/id/draft-roach-martini-up-00.txt 12:00 PM - 12:20 PM PT SIP Implicit Registrations, Presenter: Hadriel Kaplan (20 minutes) http://www.ietf.org/id/draft-kaplan-martini-shaken-implicit-registrations-00 .txt 12:20 PM - 12:30 PM PT Domain Registration, Hadriel Kaplan (10 minutes) http://www.ietf.org/id/draft-kaplan-martini-stirred-domain-registration-00.t xt Wrap-up (30 minutes) 12:30 PM - 12:40 PM PT Discussion: Participants (10 minutes) 12:40 PM - 12:55 PM PT Hums: WG Chairs (15 minutes) 12:55 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0210_01CA8EA8.A952DB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual = Interim

January 7, = 2010

11 AM – 1:00 PM = Pacific Time

 

Conferencing Details: =

 

Slide = Presentations:  http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/

Jabber room:  = martini at jabber.ietf.org (Please join)

Dial in Audioconference = and WebEx details: 

http://www.ietf.org/mail-archive/web/martini/curren= t/msg00029.html

 

Agenda

 

11 AM - 11:10 AM = PT:  Preliminaries

     Conference issues/debugging

     Agenda bash

 

Problem Statement & = Existing Deployed Solutions (30 minutes)

 

11:10 AM - 11:40 = AM  PT SIP IP-PBX Registration Problems, Hadriel Kaplan (30 = minutes)

http://www.ietf.org/id/draft-kaplan-martini-mixing-= problems-00.txt

 

Potential Solutions (50 = minutes)

 

11:40 AM – 12:00 = PM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (20 = minutes)

http://www.ietf.org/id/draft-roach-martini-up-00.txt

 

12:00 PM - 12:20 PM = PT  SIP Implicit Registrations, Presenter: Hadriel Kaplan (20 = minutes)

http://www.ietf.org/id/draft-kaplan-martini-shaken-= implicit-registrations-00.txt

 

12:20 PM - 12:30 PM PT = Domain Registration, Hadriel Kaplan (10 minutes)

http://www.ietf.org/id/draft-kaplan-martini-stirred= -domain-registration-00.txt

 

Wrap-up (30 = minutes)

 

12:30 PM - 12:40 PM = PT  Discussion:  Participants (10 minutes)

12:40 PM - 12:55 PM = PT  Hums:  WG Chairs (15 minutes)

12:55 PM - 1:00 PM = PT   Next Steps:  WG Chairs & ADs (5 minutes)

------=_NextPart_000_0210_01CA8EA8.A952DB70-- From adam@nostrum.com Wed Jan 6 08:17:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A074F3A688C for ; Wed, 6 Jan 2010 08:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa-UmFtbid8w for ; Wed, 6 Jan 2010 08:17:27 -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 5BDFB3A684F for ; Wed, 6 Jan 2010 08:17:27 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o06GHN2W028936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 10:17:23 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B44B793.30002@nostrum.com> Date: Wed, 06 Jan 2010 10:17:23 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:17:28 -0000 On 1/6/10 8:50 AM, DRAGE, Keith (Keith) wrote: > 1) Additional indicator > -------------------------- > > draft-kaplan-martini-mixing-problems-00 seems to be arguing for an indicator, but I am left in doubt as to what that indicator is for. While I am not opposed to the creation of new indicators, any indicator needs clear requirements, and a clear understanding of why it is needed. > > Is it: > > A) to indicate that implicit registration is being used. But implicit registration has existed for all IMS usages since day one. There is a massive and radical difference between the kind of implicit registration used by IMS and what is being proposed in MARTINI. Specifically: when IMS performs implicit registration, it is for several AORs that correspond to the exact same user. The MARTINI problem involves registering information for several AORs that correspond to a multitude of users. From a semantic perspective, that is a very different kind of operation. We need to be careful not to conflate these two different operations. > I do not think this document adequately addresses a set of > requirements, and I suspect a set of clearly stated requirements do > need to be put in place before further significant further work is > performed. I agree. I think the problem here is that the requirements were written primarily to support an already-developed solution, without first analyzing whether the solution really makes sense. Rather than working backwards from the broken solutions that have been deployed so far, let's actually figure out the requirements, and then work forwards from there. /a From bernard_aboba@hotmail.com Wed Jan 6 08:18:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B25D3A68F9 for ; Wed, 6 Jan 2010 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_40=-0.185, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLUxziFyH17R for ; Wed, 6 Jan 2010 08:18:21 -0800 (PST) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by core3.amsl.com (Postfix) with ESMTP id 4214F3A688C for ; Wed, 6 Jan 2010 08:18:21 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 08:18:20 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: , Date: Wed, 6 Jan 2010 08:18:44 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqDSTBDXT4DjBfyTk6dKLohaQFE6ALorpIg Content-Language: en-us X-OriginalArrivalTime: 06 Jan 2010 16:18:20.0036 (UTC) FILETIME=[DC716C40:01CA8EEB] Subject: [martini] Update: MARTINI Virtual Interim, January 7, 2010 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:18:22 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org ATTENDEE;CN='jon.peterson@neustar.biz';RSVP=TRUE:mailto:jon.peterson@neusta r.biz CLASS:PUBLIC CREATED:20100106T161843Z DESCRIPTION:When: Thursday\, January 07\, 2010 11:00 AM-1:30 PM (UTC-08:00) Pacific Time (US & Canada).\nWhere: https://workgreen.webex.com/workgreen /j.php?ED=131012752&UID=1110677752&PW=NNjRjYjAzNDVj&RT=MiM3 \n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~* ~*~*~*~*~*~*~*~*\n\nIETF Secretariat invites you to attend this online mee ting. \n\nTopic: Martini WG Virtual Meeting \nDate: Thursday\, January 7\, 2010 \nTime: 11:00 am\, Pacific Time (GMT-08:00) \nMeeting Number: 961 98 2 327 \nMeeting Password: martini \n\n\n---------------------------------- --------------------- \nTo join the online meeting (Now from iPhones too!) \n------------------------------------------------------- \n1. Go to http s://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=1110677752&PW=NNj RjYjAzNDVj&RT=MiM3 \n2. Enter your name and email address. \n3. Enter the meeting password: martini \n4. Click "Join Now". \n\nTo view in other time zones or languages\, please click the link: \nhttps://workgreen.webex.com /workgreen/j.php?ED=131012752&UID=1110677752&PW=NNjRjYjAzNDVj&ORT=MiM3 \n\ n------------------------------------------------------- \nTo join the aud io conference only \n----------------------------------------------------- -- \nTo receive a call back\, provide your phone number when you join the meeting\, or call the number below and enter the access code. \nCall-in to ll number (US/Canada): 1-408-792-6300 \nGlobal call-in numbers: https://wo rkgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=131012752&t ollFree=0 \n\nAccess code:961 982 327 \n\n-------------------------------- ----------------------- \nFor assistance \n------------------------------- ------------------------ \n1. Go to https://workgreen.webex.com/workgreen/ mc \n2. On the left navigation bar\, click "Support". \n\nYou can contact me at: \namorris@amsl.com \n1-510-492-4081 \n\nTo add this meeting to your calendar program (for example Microsoft Outlook)\, click this link: \nhtt ps://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=1110677752&ICS=M I&LD=1&RD=2&ST=1&SHA2=S077yUqV0ofHSq-PMxL5msi2bEZ05DYLHo/Yq6aLYEQ=&RT=MiM3 \n\nThe playback of UCF (Universal Communications Format) rich media file s requires appropriate players. To view this type of rich media files in t he meeting\, please check whether you have the players installed on your c omputer by going to https://workgreen.webex.com/workgreen/systemdiagnosis. php \n\nSign up for a free trial of WebEx \nhttp://www.webex.com/go/mcemfr eetrial \n\nhttp://www.webex.com \n\n\n\nIMPORTANT NOTICE: This WebEx serv ice includes a feature that allows audio and any documents and other mater ials exchanged or viewed during the session to be recorded. By joining thi s session\, you automatically consent to such recordings. If you do not co nsent to the recording\, do not join the session. \n\nMARTINI Virtual Inte rim\nJanuary 7\, 2010\n11 AM – 1:00 PM Pacific Time\n\nConferencing Deta ils: \n\nSlide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-I nterim/\nJabber room: martini at jabber.ietf.org (Please join)\nDial in A udioconference and WebEx details: \nhttp://www.ietf.org/mail-archive/web/ martini/current/msg00029.html\n\nAgenda\n\n11 AM - 11:10 AM PT: Prelimina ries\n Conference issues/debugging\n Agenda bash\n\nProblem Statem ent & Existing Deployed Solutions (30 minutes)\n\n11:10 AM - 11:40 AM PT SIP IP-PBX Registration Problems\, Hadriel Kaplan (30 minutes)\nhttp://www .ietf.org/id/draft-kaplan-martini-mixing-problems-00.txt\n\nPotential Solu tions (50 minutes)\n\n11:40 AM – 12:00 PM PT Multiple AOR Registrations in SIP\, Presenter: Adam Roach (20 minutes)\nhttp://www.ietf.org/id/draft- roach-martini-up-00.txt\n\n12:00 PM - 12:20 PM PT SIP Implicit Registrati ons\, Presenter: Hadriel Kaplan (20 minutes)\nhttp://www.ietf.org/id/draft -kaplan-martini-shaken-implicit-registrations-00.txt\n\n12:20 PM - 12:30 P M PT Domain Registration\, Hadriel Kaplan (10 minutes)\nhttp://www.ietf.or g/id/draft-kaplan-martini-stirred-domain-registration-00.txt \n\nWrap-up ( 30 minutes)\n\n12:30 PM - 12:40 PM PT Discussion: Participants (10 minut es)\n12:40 PM - 12:55 PM PT Hums: WG Chairs (15 minutes)\n12:55 PM - 1:0 0 PM PT Next Steps: WG Chairs & ADs (5 minutes)\n\n DTEND:20100107T213000Z DTSTAMP:20100106T161843Z DTSTART:20100107T190000Z LAST-MODIFIED:20100106T161843Z LOCATION:https://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=11106 77752&PW=NNjRjYjAzNDVj&RT=MiM3 ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:3 SUMMARY;LANGUAGE=en-us:Update: MARTINI Virtual Interim\, January 7\, 2010 TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000408720220683CA01000000000000000 010000000DA6110A441C06645A498881E714794AD X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Thursday\, January 07\, 2010 11:00 AM-1:30 PM (UTC-08:00) Pacific Time (US &\; Can ada).

\n\n

Where: https://workgreen.webex.com/workgreen/j.php?ED=131012752&U ID=1110677752&PW=NNjRjYjAzNDVj&RT=MiM3

\n\n

Note: The GMT offset above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~ *~*~*~*

\n\n

IETF Secretariat invites you to attend this online meeting.
\n
\nTopic: Martini WG Virtual Meeting
\nDate: T hursday\, January 7\, 2010
\nTime: 11:00 am\, Pacific Time (GMT-08:00)< BR>\nMeeting Number: 961 982 327
\nMeeting Password: martini
\n
\ n
\n-------------------------------------------------------
\nTo joi n the online meeting (Now from iPhones too!)
\n------------------------ -------------------------------
\n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131012752&\;UID=11106 77752&\;PW=NNjRjYjAzNDVj&\;RT=MiM3
\n2. Enter your name and email address.
\n3. Enter the meeting password: martini
\n4. Click "\;Join Now"\;.
\n
\ nTo view in other time zones or languages\, please click the link:
\nhttps://workgreen.webex.com/workgreen/j.php? ED=131012752&\;UID=1110677752&\;PW=NNjRjYjAzNDVj&\;ORT=MiM3
\n
\n---------------------- ---------------------------------
\nTo join the audio conference only\n-------------------------------------------------------
\nTo receiv e a call back\, provide your phone number when you join the meeting\, or c all the number below and enter the access code.
\nCall-in toll number ( US/Canada): 1-408-792-6300
\nGlobal call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC &\;ED=131012752&\;tollFree=0
\n
\nAccess code:961 982 327
\n
\n--------------------- ----------------------------------
\nFor assistance
\n-------------- -----------------------------------------
\n1. Go to < SPAN LANG="en-us">https://workgreen.webex.com/workgreen/mc
\n2. On the left navigation bar\, click &q uot\;Support"\;.
\n
\nYou can contact me at:
\n amorris@amsl.com
\n1-5 10-492-4081
\n
\nTo add this meeting to your calendar program (for e xample Microsoft Outlook)\, click this link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=131012752&\;UID= 1110677752&\;ICS=MI&\;LD=1&\;RD=2&\;ST=1&\;SHA2=S077yUqV0of HSq-PMxL5msi2bEZ05DYLHo/Yq6aLYEQ=&\;RT=MiM3
\n
\nThe playback of UCF (Universal Communication s Format) rich media files requires appropriate players. To view this type of rich media files in the meeting\, please check whether you have the pl ayers installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosi s.php
\n
\nSign up for a free trial of WebEx
\nhttp://www.webe x.com/go/mcemfreetrial
\n
\nhttp://www.webex.com
\n
\n
\n
\nIMPORTANT NOTICE: This WebEx service i ncludes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this ses sion\, you automatically consent to such recordings. If you do not consent to the recording\, do not join the session.

\n\n

\n\n

MARTIN I Virtual Interim

\n\n

January 7\, 2010

\n\n

11 AM – 1:00 PM Pacific Time

\n\n

Conferencin g Details:

\n\n

Slide Presentations:  http://www.drizzle.com/~aboba/MARTINI/Jan-I nterim/

\n\n

Jabber room:  martini at jabber.ietf.org (Please join)

\n\n

Dial in Audioconference an d WebEx details: 

\n\n

http://www.ietf.org/mai l-archive/web/martini/current/msg00029.html

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

      Conference issues/debugging

\n\n

     Agenda bash

\n \n

Problem Statement &a mp\; Existing Deployed Solutions (30 minutes)

\n\n

11:10 AM - 11:40 AM  PT SIP IP-PBX Registration Problems\, Hadriel Kaplan (30 minutes)\n\n

http://www.ietf.org/id/draft-kaplan-martini-mixing-problem s-00.txt

\n\n

Potent ial Solutions (50 minutes)

\n\n

11:40 AM – 12:00 PM PT Multiple AOR Registrati ons in SIP\, Presenter: Adam Roach (20 minutes)

\n\n

http://ww w.ietf.org/id/draft-roach-martini-up-00.txt

\n\n

12:00 PM - 12:20 PM PT  SIP Implicit Registr ations\, Presenter: Hadriel Kaplan (20 minutes)

\n\n

http://www.ietf.org/id/draft-kaplan-martini-shaken-impl icit-registrations-00.txt< SPAN LANG="en-us">

\n\n

12:20 PM - 12:30 PM PT Domain Registration\, Hadriel Kaplan (10 minutes)

\n\n

http://www.ietf.org/i d/draft-kaplan-martini-stirred-domain-registration-00.txt < /FONT>

\n\n

W rap-up (30 minutes)

\n\n

12:30 PM - 12:40 PM PT  Discussion:  Participants (10 minutes)

\n\n

12:40 PM - 12:55 PM PT  Hums:  WG Chairs (15 minutes)

\n\n

12:55 PM - 1:00 PM PT   Next Steps:  WG Chairs &\; ADs (5 minutes)

\n\n

< /P>\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:2 X-MS-OLK-APPTSEQTIME:20100106T060816Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Wed Jan 6 08:49:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725F128C0F1 for ; Wed, 6 Jan 2010 08:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.563, 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 Nre0glgPc5Kj for ; Wed, 6 Jan 2010 08:49:02 -0800 (PST) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 9AEAB28C0E1 for ; Wed, 6 Jan 2010 08:49:02 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 08:49:00 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 6 Jan 2010 08:49:29 -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: AcqO6a6F8aR8gJHSQHuhZApf8HhGYwABnwcA Content-Language: en-us X-OriginalArrivalTime: 06 Jan 2010 16:49:00.0764 (UTC) FILETIME=[259A39C0:01CA8EF0] Subject: [martini] FW: draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 16:49:03 -0000 -----Original Message----- From: Adam Roach [mailto:adam@estacado.net] Sent: Wednesday, January 06, 2010 8:01 AM To: martini@ietf.org Subject: draft-roach-martini-up-00 I have put together a draft that demonstrates several mechanisms that can be used to achieve MARTINI's goals while avoiding the pitfalls that occur with some of the currently deployed mechanisms and proposals. There is still some room for additional fleshing out and other improvements, but the current document contains enough information to convey the basic ideas, and demonstrate feasibility of the proposed mechanisms: http://www.ietf.org/id/draft-roach-martini-up-00.txt /a From drage@alcatel-lucent.com Wed Jan 6 09:06:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF103A690B for ; Wed, 6 Jan 2010 09:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=2.000, 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 auy+L6QNvVK5 for ; Wed, 6 Jan 2010 09:06:06 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id A0C4C3A6911 for ; Wed, 6 Jan 2010 09:06:06 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o06H61Xd020730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jan 2010 18:06:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Jan 2010 18:06:01 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Wed, 6 Jan 2010 18:05:59 +0100 Thread-Topic: [martini] Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO677nE822yZazSkezG8ZmAqdlSAABGf5A Message-ID: References: <4B44B793.30002@nostrum.com> In-Reply-To: <4B44B793.30002@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "martini@ietf.org" Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:06:08 -0000 You wrote: > There is a massive and radical difference between the kind of=20 > implicit registration used by IMS and what is being proposed=20 > in MARTINI.=20 > Specifically: when IMS performs implicit registration, it is=20 > for several AORs that correspond to the exact same user. The=20 > MARTINI problem involves registering information for several=20 > AORs that correspond to a multitude of users. From a semantic=20 > perspective, that is a very different kind of operation. We=20 > need to be careful not to conflate these two different operations. >=20 Whatever we end up doing is a frig as far as I can see. The problem space w= e are addressing here is how to deal with the support of URIs hosted in net= work B when a request is received containing that URI by network A. The cor= rect solution for that is DNS and / or ENUM. That is defined as one solutio= n by 3GPP and ETSI, and is called the peering-based solution. However service providers want a mechanism of using the existing interface = they give to normal customers to support PBXs. So the question is how to ta= ke a normal inbound / outbound proxy interface and make it look like a peer= ing based interface as much as possible, because that is what the PBX shoul= d be expecting at its gateway proxies. In other words, how do we get such i= nterfaces to simulate the normal gateway proxy behaviour for incoming calls= . 3GPP / ETSI call this the subscription-based approach. That is the only r= eason REGISTER is used, because it forms an integral part of such interface= s in the first place. Service providers want this solution because among ot= her things, it gives a means of managing their PBX customers in the same ma= nner as they manage their other subscribers, i.e. the same interface to the= subscriber database gets used. Use a different method, and you essentially say we are creating a new inter= face to service providers, not frigging the existing UA one. As soon as one= does that, then you are back to essentially the normal peering, and any ju= stification for the work you are suggesting should be supported by requirem= ents coming out of SPEERMINT, because it there should be no different to th= e requirements for peering any two networks using standard mechanisms. I would stress that in the scenario we are talking about the customer subsc= ription is NOT that of the end user. It is the subscription of the PBX oper= ator, and tells the SSP how it requires the URIs that it owns to be managed= by the SSP. The PBX operator decides how it delivers service to its own en= d users. So as far as the SSP is concerned there is ONE user, it is the PBX= operator. There are obviously two issues here we need to hammer out on the call tomor= row. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Wednesday, January 06, 2010 4:17 PM > To: DRAGE, Keith (Keith) > Cc: martini@ietf.org > Subject: Re: [martini] Comments on=20 > draft-kaplan-martini-mixing-problems-00 >=20 > On 1/6/10 8:50 AM, DRAGE, Keith (Keith) wrote: > > 1) Additional indicator > > -------------------------- > > > > draft-kaplan-martini-mixing-problems-00 seems to be arguing=20 > for an indicator, but I am left in doubt as to what that=20 > indicator is for. While I am not opposed to the creation of=20 > new indicators, any indicator needs clear requirements, and a=20 > clear understanding of why it is needed. > > > > Is it: > > > > A) to indicate that implicit registration is being used.=20 > But implicit registration has existed for all IMS usages=20 > since day one. >=20 >=20 > There is a massive and radical difference between the kind of=20 > implicit registration used by IMS and what is being proposed=20 > in MARTINI.=20 > Specifically: when IMS performs implicit registration, it is=20 > for several AORs that correspond to the exact same user. The=20 > MARTINI problem involves registering information for several=20 > AORs that correspond to a multitude of users. From a semantic=20 > perspective, that is a very different kind of operation. We=20 > need to be careful not to conflate these two different operations. >=20 > > I do not think this document adequately addresses a set of=20 > > requirements, and I suspect a set of clearly stated requirements do=20 > > need to be put in place before further significant further work is=20 > > performed. >=20 > I agree. I think the problem here is that the requirements=20 > were written primarily to support an already-developed=20 > solution, without first analyzing whether the solution really=20 > makes sense. Rather than working backwards from the broken=20 > solutions that have been deployed so far, let's actually=20 > figure out the requirements, and then work forwards from there. >=20 > /a > = From drage@alcatel-lucent.com Wed Jan 6 09:14:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C823A6924 for ; Wed, 6 Jan 2010 09:14:43 -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=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 4p+XqXHdcvqX for ; Wed, 6 Jan 2010 09:14:39 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 136B33A6911 for ; Wed, 6 Jan 2010 09:14:33 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o06HETEC021002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jan 2010 18:14:29 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 6 Jan 2010 18:14:29 +0100 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "martini@ietf.org" Date: Wed, 6 Jan 2010 18:12:34 +0100 Thread-Topic: [martini] MARTINI Virtual Interim Agenda Thread-Index: AcqOljeaegsNu+x0SvOvqR19RXBY/QAVBBrAAAI2KNA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE209DCD15AFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [martini] MARTINI Virtual Interim Agenda X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:14:43 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE209DCD15AFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You have hums on the agenda. Can you tell me how you intend to conduct any hums. Over the audio, Webex chat or jabber. At the moment I don't have the jabber component on that equation, audio mix= ing will not handle a hum unless you poll individuals one by one, and I sus= pect other people on the call will not have Webex up in front of them. regards Keith ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Wednesday, January 06, 2010 4:17 PM To: martini@ietf.org Subject: [martini] MARTINI Virtual Interim Agenda MARTINI Virtual Interim January 7, 2010 11 AM =96 1:00 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00029.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Problem Statement & Existing Deployed Solutions (30 minutes) 11:10 AM - 11:40 AM PT SIP IP-PBX Registration Problems, Hadriel Kaplan (3= 0 minutes) http://www.ietf.org/id/draft-kaplan-martini-mixing-problems-00.txt Potential Solutions (50 minutes) 11:40 AM =96 12:00 PM PT Multiple AOR Registrations in SIP, Presenter: Adam= Roach (20 minutes) http://www.ietf.org/id/draft-roach-martini-up-00.txt 12:00 PM - 12:20 PM PT SIP Implicit Registrations, Presenter: Hadriel Kapl= an (20 minutes) http://www.ietf.org/id/draft-kaplan-martini-shaken-implicit-registrations-0= 0.txt 12:20 PM - 12:30 PM PT Domain Registration, Hadriel Kaplan (10 minutes) http://www.ietf.org/id/draft-kaplan-martini-stirred-domain-registration-00.= txt Wrap-up (30 minutes) 12:30 PM - 12:40 PM PT Discussion: Participants (10 minutes) 12:40 PM - 12:55 PM PT Hums: WG Chairs (15 minutes) 12:55 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (5 minutes) --_000_EDC0A1AE77C57744B664A310A0B23AE209DCD15AFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

You have hums on the agenda.
 
Can you tell me how you intend to conduct any=20 hums.
 
Over the audio, Webex chat or jabber.
 
At the moment I don't have the jabber component on= that=20 equation, audio mixing will not handle a hum unless you poll individuals on= e by=20 one, and I suspect other people on the call will not have Webex up in front= of=20 them.
 
regards
 
Keith

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Wednesday, January 06, 2010 4:17 PM
To:=20 martini@ietf.org
Subject: [martini] MARTINI Virtual Interim=20 Agenda

MARTINI Virtual=20 Interim

January 7,=20 2010

11 AM =96 1:00 PM Pacif= ic=20 Time

 

Conferencing Details:=20

 

Slide Presentations:&nb= sp;=20 http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/

Jabber room:  mart= ini at=20 jabber.ietf.org (Please join)

Dial in Audioconference= and=20 WebEx details: 

http://www.ietf.org/mail-archive/web/martini/curre= nt/msg00029.html

 

Agenda

 

11 AM - 11:10 AM PT:&nb= sp;=20 Preliminaries

    = ;=20 Conference issues/debugging

    = ; Agenda=20 bash

 

Problem Statement &= Existing=20 Deployed Solutions (30 minutes)

 

11:10 AM - 11:40 AM&nbs= p; PT SIP=20 IP-PBX Registration Problems, Hadriel Kaplan (30=20 minutes)

http://www.ietf.org/id/draft-kaplan-martini-mixing= -problems-00.txt

 

Potential Solutions (50= =20 minutes)

 

11:40 AM =96 12:00 PM P= T Multiple=20 AOR Registrations in SIP, Presenter: Adam Roach (20=20 minutes)

http://www.ietf.org/id/draft-roach-martini-up-00.txt

 

12:00 PM - 12:20 PM PT&= nbsp; SIP=20 Implicit Registrations, Presenter: Hadriel Kaplan (20=20 minutes)

http://www.ietf.org/id/draft-kaplan-martini-shaken= -implicit-registrations-00.txt

 

12:20 PM - 12:30 PM PT = Domain=20 Registration, Hadriel Kaplan (10 minutes)

http://www.ietf.org/id/draft-kaplan-martini-stirre= d-domain-registration-00.txt=20

 

Wrap-up (30=20 minutes)

 

12:30 PM - 12:40 PM PT&= nbsp;=20 Discussion:  Participants (10 minutes)

12:40 PM - 12:55 PM PT&= nbsp;=20 Hums:  WG Chairs (15 minutes)

12:55 PM - 1:00 PM=20 PT   Next Steps:  WG Chairs & ADs (5=20 minutes)

--_000_EDC0A1AE77C57744B664A310A0B23AE209DCD15AFRMRSSXCHMBSC3d_-- From drage@alcatel-lucent.com Wed Jan 6 09:24:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2168828B797 for ; Wed, 6 Jan 2010 09:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 ZWoighlvs9A1 for ; Wed, 6 Jan 2010 09:24:16 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C54C53A6918 for ; Wed, 6 Jan 2010 09:24:15 -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 o06HOC06022595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jan 2010 18:24:12 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 6 Jan 2010 18:24:12 +0100 From: "DRAGE, Keith (Keith)" To: "Middleton, David (NSN - US/Boca Raton)" , "martini@ietf.org" Date: Wed, 6 Jan 2010 18:24:10 +0100 Thread-Topic: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOJjAbL8Np0oWiTKit8fz3hdvqjQAC47iwAC1FcVAAA1X0YA== Message-ID: References: <4B394119.4040502@nostrum.com><4B434FA1.40300@nostrum.com><4B436B75.9050005@cisco.com> <4B436C1D.1050002@nostrum.com> <159B27ECF9D16E40BD7ABD5778522B0103B7567E@USCHEXC006.nsn-intra.net> In-Reply-To: <159B27ECF9D16E40BD7ABD5778522B0103B7567E@USCHEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:24:17 -0000 I do not believe this is a forking problem. It needs to be implemented by some form of application server which is the = addressed endpoint of the original request-URI (on behalf of the real owner= of that URI) which then generates two call requests to the user (one to hi= s UA hosted on the PBX and one to his UA hosted on the SSP). This is essent= ially no different to the shared appearance stuff documented in draft-ietf-= bliss-shared-appearances Note also that the teleworker will in any case need to be registered on the= PBX, as there will be users on the PBX who wish to call the teleworker, at= the address which belongs to the PBX operator. Do it any other way and you= essentially turn the PBX into an access gateway to a Centrex implementatio= n on the SSP (valid, but it is no longer a PBX providing services to its ow= n end users). And no, I don't propose to handle this in MARTINI - I think the solution ex= ists already. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Middleton,=20 > David (NSN - US/Boca Raton) > Sent: Wednesday, January 06, 2010 3:50 PM > To: martini@ietf.org > Subject: Re: [martini] Who designates AORs? (was Re:=20 > draft-kaplan-martini-mixing-problems: solution requirements?) >=20 > If/when the capability to standardize the sort of portability=20 > Adam mentioned is done, it should also consider the case of a=20 > teleworker > using a client that registers directly with the SSP. This=20 > aspect helps > make a case for addressing this form of portability=20 > separately as opposed to encumbering the basic reachability solution. >=20 > For clarification, the teleworker case that I am referring to=20 > is where the teleworker is also a PBX user. Requests would=20 > be forked to both the PBX and the teleworker if both are=20 > registered. This could be implemented without knowing if the=20 > teleworker has a client active behind the PBX but if we head=20 > down the path of the SSP knowing the identities behind the=20 > PBX, the call should only be forked when the user is available. >=20 > This very much complicates the feature handling at the IP PBX=20 > since the call may not be offered to it. The user could have=20 > IP PBX-hosted voice mail or other features like call=20 > forwarding that would not be invoked if the call is not=20 > routed through the IP PBX. >=20 > To be clear, my position on this is that it should be=20 > considered out-of-scope of the MARTINI WG. >=20 > David >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bruno.chatras@orange-ftgroup.com Wed Jan 6 09:24:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B273A6918 for ; Wed, 6 Jan 2010 09:24:28 -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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 V5qr75OElixZ for ; Wed, 6 Jan 2010 09:24:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 155EB28C0DF for ; Wed, 6 Jan 2010 09:24:27 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C65F82481F2; Wed, 6 Jan 2010 18:24:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id ABA43238055; Wed, 6 Jan 2010 18:24:24 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 18:24:25 +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, 6 Jan 2010 18:24:16 +0100 Message-ID: <12799_1262798664_4B44C748_12799_19697_1_9ECCF01B52E7AB408A7EB85352642141EA08C2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO677nE822yZazSkezG8ZmAqdlSAABGf5AAAEhOsA= References: <4B44B793.30002@nostrum.com> From: To: , X-OriginalArrivalTime: 06 Jan 2010 17:24:25.0060 (UTC) FILETIME=[17C81240:01CA8EF5] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.6.163336 Cc: martini@ietf.org Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:24:28 -0000 Two comments [BC]=20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de DRAGE, Keith (Keith) > Envoy=E9 : mercredi 6 janvier 2010 18:06 > =C0 : Adam Roach > Cc : martini@ietf.org > Objet : Re: [martini] Comments on=20 > draft-kaplan-martini-mixing-problems-00 >=20 > You wrote: >=20 > > There is a massive and radical difference between the kind=20 > of implicit=20 > > registration used by IMS and what is being proposed in MARTINI. > > Specifically: when IMS performs implicit registration, it is for=20 > > several AORs that correspond to the exact same user. The MARTINI=20 > > problem involves registering information for several AORs that=20 > > correspond to a multitude of users. From a semantic=20 > perspective, that=20 > > is a very different kind of operation. We need to be careful not to=20 > > conflate these two different operations. > >=20 >=20 > Whatever we end up doing is a frig as far as I can see. The=20 > problem space we are addressing here is how to deal with the=20 > support of URIs hosted in network B when a request is=20 > received containing that URI by network A. The correct=20 > solution for that is DNS and / or ENUM. That is defined as=20 > one solution by 3GPP and ETSI, and is called the=20 > peering-based solution. >=20 > However service providers want a mechanism of using the=20 > existing interface they give to normal customers to support=20 > PBXs. So the question is how to take a normal inbound /=20 > outbound proxy interface and make it look like a peering=20 > based interface as much as possible, because that is what the=20 > PBX should be expecting at its gateway proxies. In other=20 > words, how do we get such interfaces to simulate the normal=20 > gateway proxy behaviour for incoming calls. 3GPP / ETSI call=20 > this the subscription-based approach. That is the only reason=20 > REGISTER is used, because it forms an integral part of such=20 > interfaces in the first place. Service providers want this=20 > solution because among other things, it gives a means of=20 > managing their PBX customers in the same manner as they=20 > manage their other subscribers, i.e. the same interface to=20 > the subscriber database gets used. [BC]: Another reason why (some) service providers want this solution is act= ually mentioned in draft-kaplan-martini-shaken-implicit-registrations-00 ->= less provisioning. >=20 > Use a different method, and you essentially say we are=20 > creating a new interface to service providers, not frigging=20 > the existing UA one. As soon as one does that, then you are=20 > back to essentially the normal peering, and any justification=20 > for the work you are suggesting should be supported by=20 > requirements coming out of SPEERMINT, because it there should=20 > be no different to the requirements for peering any two=20 > networks using standard mechanisms. >=20 > I would stress that in the scenario we are talking about the=20 > customer subscription is NOT that of the end user. It is the=20 > subscription of the PBX operator, and tells the SSP how it=20 > requires the URIs that it owns to be managed by the SSP. The=20 > PBX operator decides how it delivers service to its own end=20 > users. So as far as the SSP is concerned there is ONE user,=20 > it is the PBX operator. [BC]: I fully agree. From my point of view this is also why using the PAU s= till makes sense in this case. >=20 > There are obviously two issues here we need to hammer out on=20 > the call tomorrow. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: Wednesday, January 06, 2010 4:17 PM > > To: DRAGE, Keith (Keith) > > Cc: martini@ietf.org > > Subject: Re: [martini] Comments on > > draft-kaplan-martini-mixing-problems-00 > >=20 > > On 1/6/10 8:50 AM, DRAGE, Keith (Keith) wrote: > > > 1) Additional indicator > > > -------------------------- > > > > > > draft-kaplan-martini-mixing-problems-00 seems to be arguing > > for an indicator, but I am left in doubt as to what that=20 > indicator is=20 > > for. While I am not opposed to the creation of new indicators, any=20 > > indicator needs clear requirements, and a clear=20 > understanding of why=20 > > it is needed. > > > > > > Is it: > > > > > > A) to indicate that implicit registration is being used.=20 > > But implicit registration has existed for all IMS usages since day=20 > > one. > >=20 > >=20 > > There is a massive and radical difference between the kind=20 > of implicit=20 > > registration used by IMS and what is being proposed in MARTINI. > > Specifically: when IMS performs implicit registration, it is for=20 > > several AORs that correspond to the exact same user. The MARTINI=20 > > problem involves registering information for several AORs that=20 > > correspond to a multitude of users. From a semantic=20 > perspective, that=20 > > is a very different kind of operation. We need to be careful not to=20 > > conflate these two different operations. > >=20 > > > I do not think this document adequately addresses a set of=20 > > > requirements, and I suspect a set of clearly stated=20 > requirements do=20 > > > need to be put in place before further significant=20 > further work is=20 > > > performed. > >=20 > > I agree. I think the problem here is that the requirements were=20 > > written primarily to support an already-developed solution, without=20 > > first analyzing whether the solution really makes sense.=20 > Rather than=20 > > working backwards from the broken solutions that have been=20 > deployed so=20 > > far, let's actually figure out the requirements, and then work=20 > > forwards from there. > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Wed Jan 6 09:25:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2A228C0D0 for ; Wed, 6 Jan 2010 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JVs5b1Pzdi5 for ; Wed, 6 Jan 2010 09:25:07 -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 2CECB28C112 for ; Wed, 6 Jan 2010 09:25:06 -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-455210; Wed, 6 Jan 2010 18:25:02 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2D66A23F0209; Wed, 6 Jan 2010 18:25:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 6 Jan 2010 18:25:02 +0100 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , Adam Roach Date: Wed, 6 Jan 2010 18:25:00 +0100 Thread-Topic: [martini] Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO677nE822yZazSkezG8ZmAqdlSAABGf5AAAD1dHA= Message-ID: References: <4B44B793.30002@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:25:09 -0000 I agree with Keith that from the PBX point of view the basic way to do thin= gs is the peering-based approach (known as static mode in the SIPconnect sp= ec) - this involves normal RFC 3261/3263 procedures. However, for the reasons Keith has stated, SSPs want to make small PBXs loo= k as much like ordinary subscribers as possible, so that they can manage th= em the same way. In addition, such small PBXs, for various reasons stated i= n the mixing-problems draft, might not be in a position to advertise throug= h DNS. From the PBX point of view, this necessitates some departure from th= e basic RFC 3261/3263 approach. That departure essentially involves being a= ble to REGISTER with the SSP, i.e., register the PBX, as an entity that act= s on behalf of its multiple users. Other than that, it is desirable from th= e PBX's perspective that SIP operates as close as possible to how it operat= es in the peering-based approach. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 06 January 2010 17:06 > To: Adam Roach > Cc: martini@ietf.org > Subject: Re: [martini] Comments on=20 > draft-kaplan-martini-mixing-problems-00 >=20 > You wrote: >=20 > > There is a massive and radical difference between the kind of=20 > > implicit registration used by IMS and what is being proposed=20 > > in MARTINI.=20 > > Specifically: when IMS performs implicit registration, it is=20 > > for several AORs that correspond to the exact same user. The=20 > > MARTINI problem involves registering information for several=20 > > AORs that correspond to a multitude of users. From a semantic=20 > > perspective, that is a very different kind of operation. We=20 > > need to be careful not to conflate these two different operations. > >=20 >=20 > Whatever we end up doing is a frig as far as I can see. The=20 > problem space we are addressing here is how to deal with the=20 > support of URIs hosted in network B when a request is=20 > received containing that URI by network A. The correct=20 > solution for that is DNS and / or ENUM. That is defined as=20 > one solution by 3GPP and ETSI, and is called the=20 > peering-based solution. >=20 > However service providers want a mechanism of using the=20 > existing interface they give to normal customers to support=20 > PBXs. So the question is how to take a normal inbound /=20 > outbound proxy interface and make it look like a peering=20 > based interface as much as possible, because that is what the=20 > PBX should be expecting at its gateway proxies. In other=20 > words, how do we get such interfaces to simulate the normal=20 > gateway proxy behaviour for incoming calls. 3GPP / ETSI call=20 > this the subscription-based approach. That is the only reason=20 > REGISTER is used, because it forms an integral part of such=20 > interfaces in the first place. Service providers want this=20 > solution because among other things, it gives a means of=20 > managing their PBX customers in the same manner as they=20 > manage their other subscribers, i.e. the same interface to=20 > the subscriber database gets used. >=20 > Use a different method, and you essentially say we are=20 > creating a new interface to service providers, not frigging=20 > the existing UA one. As soon as one does that, then you are=20 > back to essentially the normal peering, and any justification=20 > for the work you are suggesting should be supported by=20 > requirements coming out of SPEERMINT, because it there should=20 > be no different to the requirements for peering any two=20 > networks using standard mechanisms. >=20 > I would stress that in the scenario we are talking about the=20 > customer subscription is NOT that of the end user. It is the=20 > subscription of the PBX operator, and tells the SSP how it=20 > requires the URIs that it owns to be managed by the SSP. The=20 > PBX operator decides how it delivers service to its own end=20 > users. So as far as the SSP is concerned there is ONE user,=20 > it is the PBX operator. >=20 > There are obviously two issues here we need to hammer out on=20 > the call tomorrow. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com]=20 > > Sent: Wednesday, January 06, 2010 4:17 PM > > To: DRAGE, Keith (Keith) > > Cc: martini@ietf.org > > Subject: Re: [martini] Comments on=20 > > draft-kaplan-martini-mixing-problems-00 > >=20 > > On 1/6/10 8:50 AM, DRAGE, Keith (Keith) wrote: > > > 1) Additional indicator > > > -------------------------- > > > > > > draft-kaplan-martini-mixing-problems-00 seems to be arguing=20 > > for an indicator, but I am left in doubt as to what that=20 > > indicator is for. While I am not opposed to the creation of=20 > > new indicators, any indicator needs clear requirements, and a=20 > > clear understanding of why it is needed. > > > > > > Is it: > > > > > > A) to indicate that implicit registration is being used.=20 > > But implicit registration has existed for all IMS usages=20 > > since day one. > >=20 > >=20 > > There is a massive and radical difference between the kind of=20 > > implicit registration used by IMS and what is being proposed=20 > > in MARTINI.=20 > > Specifically: when IMS performs implicit registration, it is=20 > > for several AORs that correspond to the exact same user. The=20 > > MARTINI problem involves registering information for several=20 > > AORs that correspond to a multitude of users. From a semantic=20 > > perspective, that is a very different kind of operation. We=20 > > need to be careful not to conflate these two different operations. > >=20 > > > I do not think this document adequately addresses a set of=20 > > > requirements, and I suspect a set of clearly stated=20 > requirements do=20 > > > need to be put in place before further significant=20 > further work is=20 > > > performed. > >=20 > > I agree. I think the problem here is that the requirements=20 > > were written primarily to support an already-developed=20 > > solution, without first analyzing whether the solution really=20 > > makes sense. Rather than working backwards from the broken=20 > > solutions that have been deployed so far, let's actually=20 > > figure out the requirements, and then work forwards from there. > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From drage@alcatel-lucent.com Wed Jan 6 09:49:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFBB28C0FC for ; Wed, 6 Jan 2010 09:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=1.500, 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 q35ok-t8ml+f for ; Wed, 6 Jan 2010 09:49:10 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id D8B5528C0E1 for ; Wed, 6 Jan 2010 09:49:09 -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 o06Hn23Z031206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Jan 2010 18:49:02 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 6 Jan 2010 18:49:02 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , Paul Kyzivat Date: Wed, 6 Jan 2010 18:49:00 +0100 Thread-Topic: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) Thread-Index: AcqOJKhgUyGt59aiQB+R5PSP5knXWwA0tagA Message-ID: References: <4B394119.4040502@nostrum.com> <4B434FA1.40300@nostrum.com> <4B436512.7070309@cisco.com> <4B436973.5010703@nostrum.com> In-Reply-To: <4B436973.5010703@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Who designates AORs? (was Re: draft-kaplan-martini-mixing-problems: solution requirements?) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:49:11 -0000 For information, the IMS mechanism of supporting this is using a wildcarded= URI defined as follows: "consists of a delimited regular expression located either in the userinfo = portion of the SIP URI or in the telephone-subscriber portion of the Tel UR= I. The regular expression in the wildcarded PSI shall take the form of Exte= nded Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.1-2004 = Part 1 [60]. The delimiter shall be the exclamation mark character ("!"). I= f more than two exclamation mark characters are present in the userinfo por= tion or telephone-subscriber portion of a wildcarded PSI then the outside p= air of exclamation mark characters is regarded as the pair of delimiters (i= .e. no exclamation mark characters are allowed to be present in the fixed p= arts of the userinfo portion or telephone-subscriber portion)." where the reference is: [60] IEEE 1003.1-2004, Part 1: Base Definitions Extract from 3GPP TS 23.003. Note that an attached device to IMS would only see these in the P-Associate= d-URI and in the reg event package. Otherwise their use is internal to the = IMS. As such the attached device would not necessarily need to understand t= hem. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Tuesday, January 05, 2010 4:32 PM > To: Paul Kyzivat > Cc: Bernard Aboba; martini@ietf.org > Subject: Re: [martini] Who designates AORs? (was Re:=20 > draft-kaplan-martini-mixing-problems: solution requirements?) >=20 > On 1/5/10 10:13, Jan 5, Paul Kyzivat wrote: > > I agree with a lot of what Adam says here. > > > > But, is it reasonable to expect a sip request to convey several=20 > > hundred AORs? (And what if it becomes several thousand?)=20 > This is out=20 > > of the scope of what sip requests were designed to handle. > > > > If that path is taken, then next people will be asking to=20 > encode those=20 > > more tightly, such as by specifying ranges of numbers. But=20 > of course=20 > > that won't work for non-numeric addresses. It starts to=20 > look very ugly. >=20 > Yes, this is one of the most difficult problems that MARTINI=20 > must solve.=20 > And it's a problem regardless of whether the PBX suggests the=20 > AORs to register or the SSP tells the PBX which AORs it has=20 > just registered.=20 > Some message somewhere is going to have to indicate the AORs involved. >=20 > We clearly don't do ranges of numbers. But we can do a lot=20 > with patterns, which would include ranges of numbers. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bernard_aboba@hotmail.com Wed Jan 6 09:56:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0126A3A6452 for ; Wed, 6 Jan 2010 09:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 nvw256-E9KVk for ; Wed, 6 Jan 2010 09:56:21 -0800 (PST) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id 42AF628C115 for ; Wed, 6 Jan 2010 09:56:21 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.72]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 09:56:20 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'DRAGE, Keith \(Keith\)'" , References: In-Reply-To: Date: Wed, 6 Jan 2010 09:56:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0264_01CA8EB6.90439260" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqOljeaegsNu+x0SvOvqR19RXBY/QAVBBrAAAI2KNAAAWXl8A== Content-Language: en-us X-OriginalArrivalTime: 06 Jan 2010 17:56:20.0144 (UTC) FILETIME=[8D42B300:01CA8EF9] Subject: Re: [martini] MARTINI Virtual Interim Agenda X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 17:56:27 -0000 ------=_NextPart_000_0264_01CA8EB6.90439260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good question. My initial thoughts were to use Jabber on the presumption that everyone would have access to that (since it's available on every platform). Also, we were planning on using Jabber to debug potential conferencing issues. So my suggestion to everyone is to make sure you have a functioning Jabber client for the Virtual Interim tomorrow. From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, January 06, 2010 9:13 AM To: Bernard Aboba; martini@ietf.org Subject: RE: [martini] MARTINI Virtual Interim Agenda You have hums on the agenda. Can you tell me how you intend to conduct any hums. Over the audio, Webex chat or jabber. At the moment I don't have the jabber component on that equation, audio mixing will not handle a hum unless you poll individuals one by one, and I suspect other people on the call will not have Webex up in front of them. regards Keith _____ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, January 06, 2010 4:17 PM To: martini@ietf.org Subject: [martini] MARTINI Virtual Interim Agenda MARTINI Virtual Interim January 7, 2010 11 AM - 1:00 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00029.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Problem Statement & Existing Deployed Solutions (30 minutes) 11:10 AM - 11:40 AM PT SIP IP-PBX Registration Problems, Hadriel Kaplan (30 minutes) http://www.ietf.org/id/draft-kaplan-martini-mixing-problems-00.txt Potential Solutions (50 minutes) 11:40 AM - 12:00 PM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (20 minutes) http://www.ietf.org/id/draft-roach-martini-up-00.txt 12:00 PM - 12:20 PM PT SIP Implicit Registrations, Presenter: Hadriel Kaplan (20 minutes) http://www.ietf.org/id/draft-kaplan-martini-shaken-implicit-registrations-00 .txt 12:20 PM - 12:30 PM PT Domain Registration, Hadriel Kaplan (10 minutes) http://www.ietf.org/id/draft-kaplan-martini-stirred-domain-registration-00.t xt Wrap-up (30 minutes) 12:30 PM - 12:40 PM PT Discussion: Participants (10 minutes) 12:40 PM - 12:55 PM PT Hums: WG Chairs (15 minutes) 12:55 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0264_01CA8EB6.90439260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good = question.   My initial thoughts were to use Jabber on the presumption that everyone = would have access to that (since it’s available on every platform).  =  Also, we were planning on using Jabber to debug potential conferencing = issues. 

 

So my suggestion to = everyone is to make sure you have a functioning Jabber client for the Virtual = Interim tomorrow. 

 

 

From:= DRAGE, = Keith (Keith) [mailto:drage@alcatel-lucent.com]
Sent: Wednesday, January 06, 2010 9:13 AM
To: Bernard Aboba; martini@ietf.org
Subject: RE: [martini] MARTINI Virtual Interim = Agenda

 

You have hums on the agenda.

 

Can you tell me how you intend to conduct any = hums.

 

Over the audio, Webex chat or jabber.

 

At the moment I don't have the jabber component on that = equation, audio mixing will not handle a hum unless you poll individuals one by = one, and I suspect other people on the call will not have Webex up in front of = them.

 

regards

 

Keith

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, January 06, 2010 4:17 PM
To: martini@ietf.org
Subject: [martini] MARTINI Virtual Interim Agenda

MARTINI Virtual = Interim

January 7, = 2010

11 AM – 1:00 PM = Pacific Time

 

Conferencing Details: =

 

Slide = Presentations:  http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/

Jabber room:  = martini at jabber.ietf.org (Please join)

Dial in Audioconference = and WebEx details: 

http://www.ietf.org/mail-archive/web/martini/curren= t/msg00029.html

 

Agenda

 

11 AM - 11:10 AM = PT:  Preliminaries

     Conference issues/debugging

     Agenda bash

 

Problem Statement & = Existing Deployed Solutions (30 minutes)

 

11:10 AM - 11:40 = AM  PT SIP IP-PBX Registration Problems, Hadriel Kaplan (30 = minutes)

http://www.ietf.org/id/draft-kaplan-martini-mixing-= problems-00.txt

 

Potential Solutions (50 = minutes)

 

11:40 AM – 12:00 = PM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (20 = minutes)

http://www.ietf.org/id/draft-roach-martini-up-00.tx= t

 

12:00 PM - 12:20 PM = PT  SIP Implicit Registrations, Presenter: Hadriel Kaplan (20 = minutes)

http://www.ietf.org/id/draft-kaplan-martini-shaken-= implicit-registrations-00.txt

 

12:20 PM - 12:30 PM PT = Domain Registration, Hadriel Kaplan (10 minutes)

http://www.ietf.org/id/draft-kaplan-martini-stirred= -domain-registration-00.txt

 

Wrap-up (30 = minutes)

 

12:30 PM - 12:40 PM = PT  Discussion:  Participants (10 minutes)

12:40 PM - 12:55 PM = PT  Hums:  WG Chairs (15 minutes)

12:55 PM - 1:00 PM = PT   Next Steps:  WG Chairs & ADs (5 minutes)

------=_NextPart_000_0264_01CA8EB6.90439260-- From richard@shockey.us Wed Jan 6 10:02:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612B83A6905 for ; Wed, 6 Jan 2010 10:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_05=-1.11, 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 cX9-CGolp55B for ; Wed, 6 Jan 2010 10:02:53 -0800 (PST) Received: from outbound-mail-111.bluehost.com (outbound-mail-111.bluehost.com [69.89.18.7]) by core3.amsl.com (Postfix) with SMTP id 94CCE3A6452 for ; Wed, 6 Jan 2010 10:02:53 -0800 (PST) Received: (qmail 24057 invoked by uid 0); 6 Jan 2010 18:02:51 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 6 Jan 2010 18:02:51 -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=RafGOSIwGKvzPxUXuJpjjcbEHzjX+HKwrSjcyF7mPH5AFvfmbs0uxBDp7J88dky5DQ7LfZ/OCCKBNuXp5MtjaY3e9XocQHCGdj7+m+7TnsG68SHSn26fDUicP1yHFZXB; 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 1NSaDb-0002Fb-1C; Wed, 06 Jan 2010 11:02:51 -0700 From: "Richard Shockey" To: , , References: <4B44B793.30002@nostrum.com> <12799_1262798664_4B44C748_12799_19697_1_9ECCF01B52E7AB408A7EB85352642141EA08C2@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <12799_1262798664_4B44C748_12799_19697_1_9ECCF01B52E7AB408A7EB85352642141EA08C2@ftrdmel0.rd.francetelecom.fr> Date: Wed, 6 Jan 2010 13:02:42 -0500 Message-ID: <015a01ca8efa$71e483d0$55ad8b70$@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: AcqO677nE822yZazSkezG8ZmAqdlSAABGf5AAAEhOsAAANeiwA== 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: martini@ietf.org Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:02:55 -0000 Below... > > > > However service providers want a mechanism of using the > > existing interface they give to normal customers to support > > PBXs. So the question is how to take a normal inbound / > > outbound proxy interface and make it look like a peering > > based interface as much as possible, because that is what the > > PBX should be expecting at its gateway proxies. In other > > words, how do we get such interfaces to simulate the normal > > gateway proxy behaviour for incoming calls. 3GPP / ETSI call > > this the subscription-based approach. That is the only reason > > REGISTER is used, because it forms an integral part of such > > interfaces in the first place. Service providers want this > > solution because among other things, it gives a means of > > managing their PBX customers in the same manner as they > > manage their other subscribers, i.e. the same interface to > > the subscriber database gets used. > > [BC]: Another reason why (some) service providers want this solution > is actually mentioned in draft-kaplan-martini-shaken-implicit- > registrations-00 -> less provisioning. Precisely, thank you and its not just some service providers its lots of them, especially those smaller SSP's who are dealing with what I often refer to as the fractional T1/E1 market. Small and medium businesses. Typically systems where there are less than 24 concurrent sessions deployed. It is the cost of provisioning for competitive service providers that has been a principal driver in the shaken-implicit concept. In addition using shaken-implicit makes it trivial to add additional DID numbers to a customer. I would like folks to consider for a moment the real business drivers here and not just the technical issues. IMHO the martini-shaken concept fixes known interoperability problems in the field RIGHT NOW with thousands of deployments and would be very easy to modify existing code to do this. IMHO there are real long term provisioning issues between PBX's and SSP's, but it could take 24 months in the IETF to do that, if at all ( for lots of reasons I don't think the IETF does provisioning very well) and I don't think that is logically where MARTINI should go. From adam@nostrum.com Wed Jan 6 10:26:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9B728C0F6 for ; Wed, 6 Jan 2010 10:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFpApSEsiBKY for ; Wed, 6 Jan 2010 10:26:39 -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 0228B28C0F2 for ; Wed, 6 Jan 2010 10:26:38 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o06IQX0T040599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 12:26:33 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B44D5D9.4090503@nostrum.com> Date: Wed, 06 Jan 2010 12:26:33 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4B44B793.30002@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:26:40 -0000 On 1/6/10 11:05 AM, DRAGE, Keith (Keith) wrote: > I would stress that in the scenario we are talking about the customer > subscription is NOT that of the end user. It is the subscription of > the PBX operator, and tells the SSP how it requires the URIs that it > owns to be managed by the SSP. The PBX operator decides how it > delivers service to its own end users. So as far as the SSP is > concerned there is ONE user, it is the PBX operator. The issue is that the PBX needs to be able to differentiate among its own users for proper call processing -- hence the issues with "losing target information" that the mixing problems draft talks about. So, while the SSP treats the PBX as a single billing entity, there is still a need to differentiate among the individual users behind the PBX. /a From john.elwell@siemens-enterprise.com Wed Jan 6 11:56:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72AB28C15C for ; Wed, 6 Jan 2010 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 UFjbvdQzVeKY for ; Wed, 6 Jan 2010 11:56:42 -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 C83AB28C146 for ; Wed, 6 Jan 2010 11:56:41 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-456549; Wed, 6 Jan 2010 20:56:39 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 7DE0A1EB828F; Wed, 6 Jan 2010 20:56:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 6 Jan 2010 20:56:39 +0100 From: "Elwell, John" To: Adam Roach , "martini@ietf.org" Date: Wed, 6 Jan 2010 20:56:38 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqO6e2KUH+YELTVRCWVrWHdnECI2wAIALuw Message-ID: References: <4B44B489.6080708@nostrum.com> In-Reply-To: <4B44B489.6080708@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:56:43 -0000 Adam, In your proposal, there is no consideration of proxies between the PBX and = the SSP's domain proxy/registrar, and the need for the proxy/registrar to k= now the path through these proxies back to the PBX. In other words, it prov= ides contact information without path information. Using the REGISTER metho= d, the Path header field solves this problem. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 06 January 2010 16:04 > To: martini@ietf.org > Subject: [martini] draft-roach-martini-up-00 >=20 > I have put together a draft that demonstrates several mechanisms that=20 > can be used to achieve MARTINI's goals while avoiding the=20 > pitfalls that=20 > occur with some of the currently deployed mechanisms and proposals. >=20 > There is still some room for additional fleshing out and other=20 > improvements, but the current document contains enough information to=20 > convey the basic ideas, and demonstrate feasibility of the proposed=20 > mechanisms: >=20 > http://www.ietf.org/id/draft-roach-martini-up-00.txt >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From D.Hancock@CableLabs.com Wed Jan 6 12:30:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163513A6944 for ; Wed, 6 Jan 2010 12:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEC3Qqtj9CaX for ; Wed, 6 Jan 2010 12:30:18 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 10B563A685B for ; Wed, 6 Jan 2010 12:30:17 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id o06KUFMo022761; Wed, 6 Jan 2010 13:30:16 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 6 Jan 2010 13:30:15 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) 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, 6 Jan 2010 13:30:14 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60278F3FF@srvxchg3.cablelabs.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqO6e2KUH+YELTVRCWVrWHdnECI2wAIALuwAABqitA= References: <4B44B489.6080708@nostrum.com> From: "David Hancock" To: "Elwell, John" , "Adam Roach" , X-Approved: ondar Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 20:30:19 -0000 I agree with John -- having to provision this routing information manually would be a big burden for operators serving large numbers (potentially tens of thousands) of IP-PBXs. Having a dynamic way to discover this routing info makes IP-PBX deployments a lot more scalable. Outbound is another useful SIP extension available with the register-based approach. In addition to providing a NAT-traversal solution, its multiple-flow capability could be part of the high-availability solution for the IP-PBX. David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Elwell, John > Sent: Wednesday, January 06, 2010 12:57 PM > To: Adam Roach; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > Adam, >=20 > In your proposal, there is no consideration of proxies between the PBX and > the SSP's domain proxy/registrar, and the need for the proxy/registrar to > know the path through these proxies back to the PBX. In other words, it > provides contact information without path information. Using the REGISTER > method, the Path header field solves this problem. >=20 > John >=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 06 January 2010 16:04 > > To: martini@ietf.org > > Subject: [martini] draft-roach-martini-up-00 > > > > I have put together a draft that demonstrates several mechanisms that > > can be used to achieve MARTINI's goals while avoiding the > > pitfalls that > > occur with some of the currently deployed mechanisms and proposals. > > > > There is still some room for additional fleshing out and other > > improvements, but the current document contains enough information to > > convey the basic ideas, and demonstrate feasibility of the proposed > > mechanisms: > > > > http://www.ietf.org/id/draft-roach-martini-up-00.txt > > > > /a > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Wed Jan 6 18:01:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7619328C161 for ; Wed, 6 Jan 2010 18:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NGELHuduZFs1 for ; Wed, 6 Jan 2010 18:01:12 -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 64BF528C142 for ; Wed, 6 Jan 2010 18:01:12 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07219B8075542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 20:01:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B454064.4000107@nostrum.com> Date: Wed, 06 Jan 2010 20:01:08 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 02:01:13 -0000 On 1/6/10 13:56, Jan 6, Elwell, John wrote: > Adam, > > In your proposal, there is no consideration of proxies between the PBX and the SSP's domain proxy/registrar, and the need for the proxy/registrar to know the path through these proxies back to the PBX. In other words, it provides contact information without path information. Using the REGISTER method, the Path header field solves this problem. > In some rather important ways, that's a feature, not a bug. Intermediaries may choose how to handle Path and Service-Route based on the user being registered. In the case of implicit registrations for multiple users, such intermediaries will actually make incorrect policy decisions, since they'll be basing such decisions on the "To:" header field (representing the PBX), not the implicit AORs (representing the users). Because intermediaries know what REGISTER means in RFC 3261, and we're proposing to change that meaning, the only way around this particular issue is adding a "Proxy-Require" to implicit registrations, which is probably not the direction we want to take this. In terms of how to solve this class of problems with the mechanism I propose: it takes a decided lack of imagination not to be able to envision how Path and Service-Route could be applied to PUBLISH requests. You can get just over 95% of the way there by loading RFCs 3327 and 3608 into a text editor and globally replacing the string "REGISTER" with "PUBLISH". /a From bernard_aboba@hotmail.com Wed Jan 6 22:11:37 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7EF3A690E for ; Wed, 6 Jan 2010 22:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_20=-0.74, 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 9iEAyEFRlwpe for ; Wed, 6 Jan 2010 22:11:35 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id 7648D3A685B for ; Wed, 6 Jan 2010 22:11:34 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 22:11:33 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 6 Jan 2010 22:11:58 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D9_01CA8F1D.45A18FC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqPYFIQz6wi5dhGSaScmXKtSlSzFg== Content-Language: en-us x-cr-hashedpuzzle: AFI6 APLO BtQ9 B/Cq CYbC C2HQ DM43 Di3p EsSS GHkj Gamt HiSs HuBf IpMA I8UZ JFiC; 1; bQBhAHIAdABpAG4AaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F236AFA6-D30F-4B49-8EF9-E8F6A436D388}; YgBlAHIAbgBhAHIAZABhAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA=; Thu, 07 Jan 2010 06:11:59 GMT; VgBpAHIAdAB1AGEAbAAgAEkAbgB0AGUAcgBpAG0AIABTAGwAaQBkAGUAcwAgAG4AbwB3ACAAbwBuAGwAaQBuAGUA x-cr-puzzleid: {F236AFA6-D30F-4B49-8EF9-E8F6A436D388} X-OriginalArrivalTime: 07 Jan 2010 06:11:33.0299 (UTC) FILETIME=[42BFF830:01CA8F60] Subject: [martini] Virtual Interim Slides now online X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 06:11:37 -0000 ------=_NextPart_000_02D9_01CA8F1D.45A18FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Slides for the January 7, 2010 Virtual Interim (tomorrow!) are now online at this location: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim/ ------=_NextPart_000_02D9_01CA8F1D.45A18FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Slides for the January 7, 2010 Virtual Interim = (tomorrow!) are now online at this location:

http://www.dr= izzle.com/~aboba/MARTINI/Jan-Interim/

 

------=_NextPart_000_02D9_01CA8F1D.45A18FC0-- From john.elwell@siemens-enterprise.com Wed Jan 6 23:42:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29623A67A4 for ; Wed, 6 Jan 2010 23:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 RrS7sepz53cI for ; Wed, 6 Jan 2010 23: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 7260828C0E9 for ; Wed, 6 Jan 2010 23:42:41 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-458999; Thu, 7 Jan 2010 08:42:38 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id CEAAA1EB828F; Thu, 7 Jan 2010 08:42:38 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 7 Jan 2010 08:42:38 +0100 From: "Elwell, John" To: Adam Roach Date: Thu, 7 Jan 2010 08:42:36 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPPUqxXbzpgsAzQ/aQ6PBmMO5e1AALBRog Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> In-Reply-To: <4B454064.4000107@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:42:42 -0000 Adam, Sure you could specify the use of Path and Service-Route with PUBLISH, but = that is yet another aspect for the entities concerned to support. We seem t= o be getting further and further from the objective of fixing the problem t= hat exists in the field today: lots of implementations based around REGISTE= R (+ Path etc.), but differing in details such that interoperability is imp= aired. We need to nail down the details so that, with relatively minor chan= ges to the entities involved, interoperability can be achieved. The more ma= jor the changes, the longer it will take for vendors to implement, and in f= act the less likely it will be that vendors do implement. Furthermore, a simple nailing down of details of how the REGISTER-based mec= hanism works might even avoid changes to intermediate proxies, or at least = minimise those changes. A change to PUBLISH with its entirely new syntax, t= ogether with the use of things like Path and Service-Route with PUBLISH, wo= uld represent substantial changes for those intermediaries. An intermediary= would need to behave differently for a PUBLSIH in accordance with this eve= nt package (e.g., add a Path header field), compared with a PUBLISH for oth= er event packages. Not very clean. Finally, I re-iterate that the perceived benefits that the PUBLISH proposal= gives are not requirements. A PBX will generally be configured or scripted= with rules to apply to requests inbound to one if the AORs it is responsib= le for, which might include parallel or serial delivery to multiple contact= s, eventual forwarding to voicemail, or in some cases outright rejection. T= his information needs to be in the PBX, so that requests originating in the= PBX (or from some other source not arriving via the SSP) can be handled co= rrectly. Requests arriving from the SSP should be handled the same (notwith= standing the fact that the rules concerned might be impacted by the source = of the request). The idea is to deliver requests to the domain that is able= to handle them, i.e., the PBX, and for the PBX to deal with issues of noma= dicity etc., e.g., by redirection if the required contact happens to be off= -PBX. The so-called feature of the SSP being able to fork is in my opinion = a disadvantage, and results in split responsibility for an AOR, something w= hich surely is contrary to the principles of RFC 3261. Note that the multiple registrations capability in the shaken-implicit draf= t is intended for resilience purposes, not for being able to register diffe= rent contacts for different AORs. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 07 January 2010 02:01 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/6/10 13:56, Jan 6, Elwell, John wrote: > > Adam, > > > > In your proposal, there is no consideration of proxies=20 > between the PBX and the SSP's domain proxy/registrar, and the=20 > need for the proxy/registrar to know the path through these=20 > proxies back to the PBX. In other words, it provides contact=20 > information without path information. Using the REGISTER=20 > method, the Path header field solves this problem. > > =20 >=20 > In some rather important ways, that's a feature, not a bug.=20 > Intermediaries may choose how to handle Path and=20 > Service-Route based on=20 > the user being registered. In the case of implicit registrations for=20 > multiple users, such intermediaries will actually make=20 > incorrect policy=20 > decisions, since they'll be basing such decisions on the "To:" header=20 > field (representing the PBX), not the implicit AORs (representing the=20 > users). Because intermediaries know what REGISTER means in=20 > RFC 3261, and=20 > we're proposing to change that meaning, the only way around this=20 > particular issue is adding a "Proxy-Require" to implicit=20 > registrations,=20 > which is probably not the direction we want to take this. >=20 > In terms of how to solve this class of problems with the mechanism I=20 > propose: it takes a decided lack of imagination not to be able to=20 > envision how Path and Service-Route could be applied to PUBLISH=20 > requests. You can get just over 95% of the way there by loading RFCs=20 > 3327 and 3608 into a text editor and globally replacing the string=20 > "REGISTER" with "PUBLISH". >=20 > /a > = From bruno.chatras@orange-ftgroup.com Thu Jan 7 00:27:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA3703A699A for ; Thu, 7 Jan 2010 00:27:31 -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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 idkPYA-w8ZOk for ; Thu, 7 Jan 2010 00:27:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id BB2E93A699E for ; Thu, 7 Jan 2010 00:27:30 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 58BBD9C20E; Thu, 7 Jan 2010 09:27:28 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3F961238075; Thu, 7 Jan 2010 09:27:28 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 09:27: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: Thu, 7 Jan 2010 09:27:21 +0100 Message-ID: <21963_1262852848_4B459AF0_21963_14962_1_9ECCF01B52E7AB408A7EB85352642141EA0999@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B44B489.6080708@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 - P-Asserted-Identity Thread-Index: AcqO6f8f0GR/FffXRMuZJiCrjuelnwAiB7BQ References: <4B44B489.6080708@nostrum.com> From: To: , X-OriginalArrivalTime: 07 Jan 2010 08:27:29.0052 (UTC) FILETIME=[3FF51DC0:01CA8F73] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.7.75117 Subject: Re: [martini] draft-roach-martini-up-00 - P-Asserted-Identity X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 08:27:32 -0000 Question about P-Asserted-Identity handling. There are configurations where the asserion of an identity is performed by = an edge/outbound proxy (e.g. P-CSCF in case of an IMS). This requires the e= dge/outbound proxy to be aware of the list of valid values. The PAU provide= s means to convey this information to the edge/outbound proxy. What would b= e the alternative mechanism to use if the PUBLISH-based solution described = in this I-D were implemented. /BC =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Adam Roach > Envoy=E9 : mercredi 6 janvier 2010 17:04 > =C0 : martini@ietf.org > Objet : [martini] draft-roach-martini-up-00 >=20 > I have put together a draft that demonstrates several=20 > mechanisms that can be used to achieve MARTINI's goals while=20 > avoiding the pitfalls that occur with some of the currently=20 > deployed mechanisms and proposals. >=20 > There is still some room for additional fleshing out and=20 > other improvements, but the current document contains enough=20 > information to convey the basic ideas, and demonstrate=20 > feasibility of the proposed > mechanisms: >=20 > http://www.ietf.org/id/draft-roach-martini-up-00.txt >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Thu Jan 7 06:48:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB523A6810 for ; Thu, 7 Jan 2010 06:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 gK5FJlf5wxmr for ; Thu, 7 Jan 2010 06:48:14 -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 672093A67F3 for ; Thu, 7 Jan 2010 06:48:13 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07Em9vZ003593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 08:48:10 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B45F429.3080802@nostrum.com> Date: Thu, 07 Jan 2010 08:48:09 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:48:15 -0000 John: The problem with the approach you espouse below is that it is a point=20 solution for a very specific architecture. The general approach that=20 we've taken with SIP in the past is to standardize general tools that=20 can be combined to accommodate varying services and varying architectures= =2E This is, for example, why we selected draft-ietf-sip-refer over=20 draft-dean-handoff (http://tools.ietf.org/id/draft-dean-handoff-00.txt)=20 -- we recognized that defining a service-enabling tool was infinitely=20 more flexible than defining a service. In terms of "perceived benefits," I'll point out that the PUBLISH=20 proposal eliminates the vast majority of the problems described in the=20 martini-mixing-problems draft not by solving them, but by sidestepping=20 them altogether. Do I care about that? Not very much. It's not why I'm here. What's important to me is that my proposal also doesn't materially=20 change the semantics of a core SIP method -- because such changes can=20 result in potential policy violations, like the one I describe in my=20 message below. My horse in this race is "don't screw up the core SIP=20 protocol." I understand that you have a very specific problem you're=20 trying to solve, and that the least-effort approach would be to define a = laser-focused point solution that addresses precisely one architectural=20 model, with little regard for how it interacts with other architectures=20 or other parts of the protocol. I'm here to make sure there's no collateral damage. /a On 1/7/10 01:42, Jan 7, Elwell, John wrote: > Adam, > > Sure you could specify the use of Path and Service-Route with PUBLISH, = but that is yet another aspect for the entities concerned to support. We = seem to be getting further and further from the objective of fixing the p= roblem that exists in the field today: lots of implementations based arou= nd REGISTER (+ Path etc.), but differing in details such that interoperab= ility is impaired. We need to nail down the details so that, with relativ= ely minor changes to the entities involved, interoperability can be achie= ved. The more major the changes, the longer it will take for vendors to i= mplement, and in fact the less likely it will be that vendors do implemen= t. > > Furthermore, a simple nailing down of details of how the REGISTER-based= mechanism works might even avoid changes to intermediate proxies, or at = least minimise those changes. A change to PUBLISH with its entirely new s= yntax, together with the use of things like Path and Service-Route with P= UBLISH, would represent substantial changes for those intermediaries. An = intermediary would need to behave differently for a PUBLSIH in accordance= with this event package (e.g., add a Path header field), compared with a= PUBLISH for other event packages. Not very clean. > > Finally, I re-iterate that the perceived benefits that the PUBLISH prop= osal gives are not requirements. A PBX will generally be configured or sc= ripted with rules to apply to requests inbound to one if the AORs it is r= esponsible for, which might include parallel or serial delivery to multip= le contacts, eventual forwarding to voicemail, or in some cases outright = rejection. This information needs to be in the PBX, so that requests orig= inating in the PBX (or from some other source not arriving via the SSP) c= an be handled correctly. Requests arriving from the SSP should be handled= the same (notwithstanding the fact that the rules concerned might be imp= acted by the source of the request). The idea is to deliver requests to t= he domain that is able to handle them, i.e., the PBX, and for the PBX to = deal with issues of nomadicity etc., e.g., by redirection if the required= contact happens to be off-PBX. The so-called feature of the SSP being ab= le to fork is in my opinion a disadvantage, and results in split responsi= bility for an AOR, something which surely is contrary to the principles o= f RFC 3261. > > Note that the multiple registrations capability in the shaken-implicit = draft is intended for resilience purposes, not for being able to register= different contacts for different AORs. > > John > > =20 >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 07 January 2010 02:01 >> To: Elwell, John >> Cc: martini@ietf.org >> Subject: Re: [martini] draft-roach-martini-up-00 >> >> On 1/6/10 13:56, Jan 6, Elwell, John wrote: >> =20 >>> Adam, >>> >>> In your proposal, there is no consideration of proxies >>> =20 >> between the PBX and the SSP's domain proxy/registrar, and the >> need for the proxy/registrar to know the path through these >> proxies back to the PBX. In other words, it provides contact >> information without path information. Using the REGISTER >> method, the Path header field solves this problem. >> =20 >>> >>> =20 >> In some rather important ways, that's a feature, not a bug. >> Intermediaries may choose how to handle Path and >> Service-Route based on >> the user being registered. In the case of implicit registrations for >> multiple users, such intermediaries will actually make >> incorrect policy >> decisions, since they'll be basing such decisions on the "To:" header >> field (representing the PBX), not the implicit AORs (representing the >> users). Because intermediaries know what REGISTER means in >> RFC 3261, and >> we're proposing to change that meaning, the only way around this >> particular issue is adding a "Proxy-Require" to implicit >> registrations, >> which is probably not the direction we want to take this. >> >> In terms of how to solve this class of problems with the mechanism I >> propose: it takes a decided lack of imagination not to be able to >> envision how Path and Service-Route could be applied to PUBLISH >> requests. You can get just over 95% of the way there by loading RFCs >> 3327 and 3608 into a text editor and globally replacing the string >> "REGISTER" with "PUBLISH". >> >> /a >> =20 From drage@alcatel-lucent.com Thu Jan 7 06:57:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A113A687F for ; Thu, 7 Jan 2010 06:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 W1COtkREcwAA for ; Thu, 7 Jan 2010 06:57:28 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 3581A3A6800 for ; Thu, 7 Jan 2010 06:57:27 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o07EvKNX013802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 15:57:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Jan 2010 15:57:20 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Thu, 7 Jan 2010 15:57:18 +0100 Thread-Topic: [martini] Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO/cmObm3kHT4MTDmvL/TXHYSNWQAq6UpA Message-ID: References: <4B44B793.30002@nostrum.com> <4B44D5D9.4090503@nostrum.com> In-Reply-To: <4B44D5D9.4090503@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 14:57:29 -0000 I'm lost. Are you referring to the loss of the Request-URI in incoming requests? If so you will note that I commented in another message that at least in IM= S, the replacement does is not intended to occur on attached PBXs. This is = the misnamed "loose route" that is referred to in the drafts. This mechanis= m is meant to be generally applied to anyone creating a subscription as a P= BX. regards Keith=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Wednesday, January 06, 2010 6:27 PM > To: DRAGE, Keith (Keith) > Cc: martini@ietf.org > Subject: Re: [martini] Comments on=20 > draft-kaplan-martini-mixing-problems-00 >=20 > On 1/6/10 11:05 AM, DRAGE, Keith (Keith) wrote: > > I would stress that in the scenario we are talking about=20 > the customer=20 > > subscription is NOT that of the end user. It is the subscription of=20 > > the PBX operator, and tells the SSP how it requires the=20 > URIs that it=20 > > owns to be managed by the SSP. The PBX operator decides how it=20 > > delivers service to its own end users. So as far as the SSP is=20 > > concerned there is ONE user, it is the PBX operator. >=20 > The issue is that the PBX needs to be able to differentiate=20 > among its own users for proper call processing -- hence the=20 > issues with "losing target information" that the mixing=20 > problems draft talks about. So, while the SSP treats the PBX=20 > as a single billing entity, there is still a need to=20 > differentiate among the individual users behind the PBX. >=20 > /a > = From john.elwell@siemens-enterprise.com Thu Jan 7 07:27:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C960C3A67F3 for ; Thu, 7 Jan 2010 07:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 6gXeBm1jIRAN for ; Thu, 7 Jan 2010 07:27:12 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A4A553A67FB for ; Thu, 7 Jan 2010 07:27:11 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-466141; Thu, 7 Jan 2010 16:27:09 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 1B12F1EB8293; Thu, 7 Jan 2010 16:27:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jan 2010 16:27:09 +0100 From: "Elwell, John" To: Adam Roach Date: Thu, 7 Jan 2010 16:27:08 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPqHFNEu8jvPskSsGI/1rx/bqtDQABOsQA Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> In-Reply-To: <4B45F429.3080802@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:27:12 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 07 January 2010 14:48 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > John: >=20 > The problem with the approach you espouse below is that it is a point=20 > solution for a very specific architecture. The general approach that=20 > we've taken with SIP in the past is to standardize general tools that=20 > can be combined to accommodate varying services and varying=20 > architectures. >=20 > This is, for example, why we selected draft-ietf-sip-refer over=20 > draft-dean-handoff=20 > (http://tools.ietf.org/id/draft-dean-handoff-00.txt)=20 > -- we recognized that defining a service-enabling tool was infinitely=20 > more flexible than defining a service. >=20 > In terms of "perceived benefits," I'll point out that the PUBLISH=20 > proposal eliminates the vast majority of the problems=20 > described in the=20 > martini-mixing-problems draft not by solving them, but by=20 > sidestepping=20 > them altogether. >=20 > Do I care about that? Not very much. It's not why I'm here. >=20 > What's important to me is that my proposal also doesn't materially=20 > change the semantics of a core SIP method -- because such changes can=20 > result in potential policy violations, like the one I describe in my=20 > message below. My horse in this race is "don't screw up the core SIP=20 > protocol." I understand that you have a very specific problem you're=20 > trying to solve, and that the least-effort approach would be=20 > to define a=20 > laser-focused point solution that addresses precisely one=20 > architectural=20 > model, with little regard for how it interacts with other=20 > architectures=20 > or other parts of the protocol. >=20 > I'm here to make sure there's no collateral damage. [JRE] I understand that, but it is not clear to me why we can't come up wit= h a REGISTER-based proposal that is not fundamentally broken. I believe the= PUBLISH proposal is even more broken, if intermediaries have to be aware o= f the specific event package and take special action to do with Path, for e= xample. John From richard@shockey.us Thu Jan 7 07:55:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C513A686B for ; Thu, 7 Jan 2010 07:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=0.799, 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 Ml3QemGFNLmD for ; Thu, 7 Jan 2010 07:55:39 -0800 (PST) Received: from outbound-mail-19.bluehost.com (outbound-mail-19.bluehost.com [69.89.20.234]) by core3.amsl.com (Postfix) with SMTP id 85F163A6857 for ; Thu, 7 Jan 2010 07:55:39 -0800 (PST) Received: (qmail 24540 invoked by uid 0); 7 Jan 2010 15:55:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy1.bluehost.com with SMTP; 7 Jan 2010 15:55:37 -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=G50uAsGLA0F0T80TW+Da3RNBsb+rAehMKWvNjO3d5E9cvyKQqs0+/EMHKiMPmzsVRAvvv7EFRd0UJrt8Wq2UsM/CQmYZ8SHpk3aLG8SFkTv17U/XOWP3rVKwMFJx8MpN; 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 1NSui1-0001Pl-JA; Thu, 07 Jan 2010 08:55:37 -0700 From: "Richard Shockey" To: "'Adam Roach'" , "'Elwell, John'" References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> In-Reply-To: <4B45F429.3080802@nostrum.com> Date: Thu, 7 Jan 2010 10:55:29 -0500 Message-ID: <00e001ca8fb1$d6bffc50$843ff4f0$@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: AcqPqHHMF0K++8IbTp+UlaRoDHWFFQABiGhw 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: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 15:55:40 -0000 > In terms of "perceived benefits," I'll point out that the PUBLISH > proposal eliminates the vast majority of the problems described in the > martini-mixing-problems draft not by solving them, but by sidestepping > them altogether. Adam you are not listing to some of us. > > Do I care about that? Not very much. It's not why I'm here. > > What's important to me is that my proposal also doesn't materially > change the semantics of a core SIP method -- because such changes can > result in potential policy violations, like the one I describe in my > message below. My horse in this race is "don't screw up the core SIP > protocol." Good grief Adam we are not screwing up the core SIP protocol. What a preposterous statement. That was done by others a long time ago. You have not convinced me or some us that going off into an entirely different direction, as you propose, fixes the relatively simple problem in the field we are collectively encountering. Nor does your solution fix the larger issue of provisioning between PBX's and SSP. That larger issue is a question for another day. I understand that you have a very specific problem you're > trying to solve, and that the least-effort approach would be to define > a laser-focused point solution that addresses precisely one > architectural model, with little regard for how it interacts with other > architectures or other parts of the protocol. > > I'm here to make sure there's no collateral damage. IMHO you have not made your case that martini-shaken would cause any damage at all especially since the REGISTER method is very very widely deployed now and actually works ..if somewhat inconsistently which is the simple problem we are trying to solve without having to force a major revision to existing code bases. Ok I understand why some people do not like martini-shaken but once and a while duct tape and baling wire actually works. Some of us have looked at this problem for nearly 16 months and we came to the inevitable conclusion that the martini-shaken solution was in fact the best way to proceed. What I want to make sure is that there is no collateral damage to the SIP industry as a whole. If we ( IETF ) continue to make it difficult, if not impossible to address very simple interoperability problems in a timely fashion with the DISPATCH process what vendors and SSP's will ultimately do is run off on their own with even more damage to SIP than has already been done. From adam@nostrum.com Thu Jan 7 08:02:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B441A3A68BE for ; Thu, 7 Jan 2010 08:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 kKtcSNN8lniL for ; Thu, 7 Jan 2010 08:02:04 -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 979163A68B4 for ; Thu, 7 Jan 2010 08:02:03 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07G20gK009521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 10:02:00 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B460578.4050601@nostrum.com> Date: Thu, 07 Jan 2010 10:02:00 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:02:04 -0000 On 1/7/10 09:27, Jan 7, Elwell, John wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> >> ... >> >> I'm here to make sure there's no collateral damage. >> > [JRE] I understand that, but it is not clear to me why we can't come up with a REGISTER-based proposal that is not fundamentally broken. Because using REGISTER to talk about multiple users is fundamentally broken. It's not what REGISTER means. And there are SIP implementations out there that do know what REGISTER means. You are changing a fundamental property of a core SIP construct -- the operation no longer applies to just the user indicated in the "To" header field; it applies to myriad disparate users. Intermediaries assuming it means what RFC 3261 says it means will be mislead, and make potentially incorrect policy decisions as a consequence. > I believe the PUBLISH proposal is even more broken, if intermediaries have to be aware of the specific event package and take special action to do with Path, for example. > We *want* intermediaries to be aware of what's going on. It would be an error to let them continue to operate as if this were a REGISTER request for a single user. Without a "Proxy-Require," the only way to do this is not to use REGISTER. /a From john.elwell@siemens-enterprise.com Thu Jan 7 08:23:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6D33A6809 for ; Thu, 7 Jan 2010 08:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 of-sjKzDmC-0 for ; Thu, 7 Jan 2010 08:23:42 -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 E40433A67FB for ; Thu, 7 Jan 2010 08:23:39 -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-467089 for martini@ietf.org; Thu, 7 Jan 2010 17:23:37 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 51E0E1EB828F for ; Thu, 7 Jan 2010 17:23:37 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 7 Jan 2010 17:23:37 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Thu, 7 Jan 2010 17:23:36 +0100 Thread-Topic: Requirements Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQ== 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: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:23:43 -0000 It has been pointed out to me that the materials for today's meeting are ra= ther lacking in requirements. Coming up with a complete set of requirements= at short notice is not easy, but a few of the requirements would be along = the following lines. Perhaps others could help me refine these on the list,= so we have a basis for requirements discussion today. - The mechanism MUST allow the PBX to be responsible for its AORs and to ha= ndle requests to those AORs according to its rules. - The mechanism MUST allow the PBX to receive requests to its AORs that ori= ginate off-PBX and arrive via the SSP, so that the PBX can handle those req= uests according to its rules. - The mechanism MUST provide a means whereby the PBX knows which of its AOR= s an inbound request is targeted at.- The mechanism MUST provide a means of= avoiding problems due to one side using the mechanism when the other side = does not support it or is not using it. - The mechanism MUST work in the presence of intermediate "proxies" between= the PBX and the SSP's domain proxy, where those intermediate "proxies" nee= d to be on the path of inbound requests to the PBX. - The mechanism MUST work when the PBX obtains its IP address dynamically. - The mechanism MUST work without requiring the PBX to publish reachability= information through the DNS. Also some desiderata: - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing S= IP service to ordinary subscribers in order to provide a SIP trunking servi= ce to PBXs. - The mechanism SHOULD scale to PBXs of several thousand users. - The mechanism SHOULD require relatively modest changes to a substantial p= opulation of existing SSP and PBX implementations, in order to encourage a = fast market adoption of the standardized mechanism. John From adam@nostrum.com Thu Jan 7 08:25:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860113A67FB for ; Thu, 7 Jan 2010 08:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 b+6WRNeYPlba for ; Thu, 7 Jan 2010 08:25: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 452263A63C9 for ; Thu, 7 Jan 2010 08:25:34 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07GPU8w011298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 10:25:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B460AFA.9010008@nostrum.com> Date: Thu, 07 Jan 2010 10:25:30 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Richard Shockey References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> In-Reply-To: <00e001ca8fb1$d6bffc50$843ff4f0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:25:35 -0000 On 1/7/10 09:55, Jan 7, Richard Shockey wrote: > Adam you are not listing to some of us. That's funny -- I get the impression that the key issue I'm raising isn't being listened to either. At least, no one has addressed how intermediaries are going to know that this is not an ordinary REGISTER request in a way that doesn't effectively make the output of MARTINI a mandatory-to-implement part of the core SIP protocol. > Good grief Adam we are not screwing up the core SIP protocol. What a > preposterous statement. That was done by others a long time ago. "Well, he appears to have a contusion on his leg. Certainly it's okay break his arm, since he's already injured." > Nor does your solution fix the larger issue of provisioning between PBX's and SSP. If you've read something that you think implied that it did, I assure you that you've missed the point of whatever you were reading at the time. Go back and find the intended meaning. > IMHO you have not made your case that martini-shaken would cause any > damage at all especially since the REGISTER method is very very widely > deployed now and actually works .. The fact that it works in a specific architecture says nothing about how it interacts with other architectures. The proposed changes to REGISTER are simply not backwards compatible with the protocol as it has already been defined. A change in semantics without an indicator that will alert all interested parties of the change in semantics is a recipe for disaster. And intermediaries are a party to REGISTER transactions, for better or for worse. /a From bruno.chatras@orange-ftgroup.com Thu Jan 7 08:28:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97DD3A6809 for ; Thu, 7 Jan 2010 08:28:18 -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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 tIcuwG0bJjZB for ; Thu, 7 Jan 2010 08:28:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id BC7DF3A63C9 for ; Thu, 7 Jan 2010 08:28:17 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6981D104507; Thu, 7 Jan 2010 17:28:15 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5054C4C06C; Thu, 7 Jan 2010 17:28:15 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 17:28:15 +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, 7 Jan 2010 17:28:14 +0100 Message-ID: <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B460578.4050601@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPsugM0qxgzfU6TfOYRNFjOay0XAAAmZ4g References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> From: To: , X-OriginalArrivalTime: 07 Jan 2010 16:28:15.0695 (UTC) FILETIME=[69E585F0:01CA8FB6] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.7.155118 Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:28:19 -0000 I'm not sure I understand why using REGISTER for the PBX case is fundamenta= lly broken. Is there a fundamental difference between a small PBX and a SIP= -aware Home/Residential Gateway serving a couple of lines/numbers/users in = one house? Or would you also argue that such a HGW should also use the PUBL= ISH method? /BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Adam Roach > Envoy=E9 : jeudi 7 janvier 2010 17:02 > =C0 : Elwell, John > Cc : martini@ietf.org > Objet : Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 09:27, Jan 7, Elwell, John wrote: > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> > >> ... > >> > >> I'm here to make sure there's no collateral damage. > >>=20=20=20=20=20=20 > > [JRE] I understand that, but it is not clear to me why we=20 > can't come up with a REGISTER-based proposal that is not=20 > fundamentally broken. >=20 > Because using REGISTER to talk about multiple users is=20 > fundamentally broken. It's not what REGISTER means. And there=20 > are SIP implementations out there that do know what REGISTER=20 > means. You are changing a fundamental property of a core SIP=20 > construct -- the operation no longer applies to just the user=20 > indicated in the "To" header field; it applies to myriad=20 > disparate users. Intermediaries assuming it means what RFC > 3261 says it means will be mislead, and make potentially=20 > incorrect policy decisions as a consequence. >=20 > > I believe the PUBLISH proposal is even more broken, if=20 > intermediaries have to be aware of the specific event package=20 > and take special action to do with Path, for example. > >=20=20=20=20 >=20 > We *want* intermediaries to be aware of what's going on. It=20 > would be an error to let them continue to operate as if this=20 > were a REGISTER request for a single user. Without a=20 > "Proxy-Require," the only way to do this is not to use REGISTER. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Thu Jan 7 08:42:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F03A3A6840 for ; Thu, 7 Jan 2010 08:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1mZGsS9tG7jO for ; Thu, 7 Jan 2010 08:42:38 -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 360AF3A6809 for ; Thu, 7 Jan 2010 08:42:37 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07GgY3f012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 10:42:34 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B460EFA.9000307@nostrum.com> Date: Thu, 07 Jan 2010 10:42:34 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:42:39 -0000 On 1/7/10 10:28, Jan 7, bruno.chatras@orange-ftgroup.com wrote: > I'm not sure I understand why using REGISTER for the PBX case is fundamentally broken. Consider the case in which the intermediary is making policy decisions based on the user being registered. If it uses the RFC 3261 definition of REGISTER, then it knows that the user under discussion is the user indicated in the "To" header field, and that policies should be applied accordingly. Once we change the semantics of REGISTER so that the user -- or users -- under discussion no longer appear in the "To" header field, then this intermediary will be relying on incorrect information for its policies. > Is there a fundamental difference between a small PBX and a SIP-aware Home/Residential Gateway serving a couple of lines/numbers/users in one house? Or would you also argue that such a HGW should also use the PUBLISH method? > I would argue that a small home gateway servicing two users would generally maintain two independent registrations using the REGISTER method. However, if they wanted to consolidate these into a single operation, then yes, the idea is that the unified way to update rendezvous information for multiple users would be using PUBLISH. /a From alan@sipstation.com Thu Jan 7 08:47:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646A03A6809 for ; Thu, 7 Jan 2010 08:47:53 -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 RXIUL5lg9XcA for ; Thu, 7 Jan 2010 08:47:52 -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 E366E3A63C9 for ; Thu, 7 Jan 2010 08:47:49 -0800 (PST) Received: from 24-107-197-239.dhcp.stls.mo.charter.com ([24.107.197.239] helo=Alans-PowerBook-G4-17.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NSvWU-000FYS-6G; Thu, 07 Jan 2010 16:47:46 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.239 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+PjkeSqLzo2dJnrhKiKiAmD6X+ncxuCn8= Message-ID: <4B46102F.9000006@sipstation.com> Date: Thu, 07 Jan 2010 10:47:43 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> In-Reply-To: <4B460578.4050601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:47:53 -0000 Adam, A question and a comment below. - Alan - Adam Roach wrote: > On 1/7/10 09:27, Jan 7, Elwell, John wrote: >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> >>> ... >>> >>> I'm here to make sure there's no collateral damage. >>> >> [JRE] I understand that, but it is not clear to me why we can't come >> up with a REGISTER-based proposal that is not fundamentally broken. > > Because using REGISTER to talk about multiple users is fundamentally > broken. It's not what REGISTER means. And there are SIP > implementations out there that do know what REGISTER means. You are > changing a fundamental property of a core SIP construct -- the > operation no longer applies to just the user indicated in the "To" > header field; it applies to myriad disparate users. Intermediaries > assuming it means what RFC 3261 says it means will be mislead, and > make potentially incorrect policy decisions as a consequence. What kinds of sensible things could an intermediary proxy do with such a REGISTER? And what problems would this cause? I could only imagine a proxy which is part of either the service provider domain or the enterprise domain doing anything sensible with the REGISTER, and both of these would recognize it as as what it is. A proxy which is not part of either of these domain *might* be subject to the confusion you point out, but I would argue this proxy should not do anything to this request except do Section 16 of RFC 3261 routing on it, and I don't believe anything will break based on what is being proposed. > >> I believe the PUBLISH proposal is even more broken, if intermediaries >> have to be aware of the specific event package and take special >> action to do with Path, for example. >> > > We *want* intermediaries to be aware of what's going on. It would be > an error to let them continue to operate as if this were a REGISTER > request for a single user. Without a "Proxy-Require," the only way to > do this is not to use REGISTER. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Thu Jan 7 08:48:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34C03A63C9 for ; Thu, 7 Jan 2010 08:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 GJLhH6NyEFr9 for ; Thu, 7 Jan 2010 08:48:05 -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 9C4C628C0DB for ; Thu, 7 Jan 2010 08:48:04 -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-467515; Thu, 7 Jan 2010 17:48:02 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4FEDA23F0209; Thu, 7 Jan 2010 17:48:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 7 Jan 2010 17:48:02 +0100 From: "Elwell, John" To: Adam Roach , Richard Shockey Date: Thu, 7 Jan 2010 17:48:01 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPtgs4zOrC6qazRsShkVW/dmHv0AAAwllw Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> In-Reply-To: <4B460AFA.9010008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:48:06 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 07 January 2010 16:26 > To: Richard Shockey > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 09:55, Jan 7, Richard Shockey wrote: >=20 > > Adam you are not listing to some of us. >=20 > That's funny -- I get the impression that the key issue I'm raising=20 > isn't being listened to either. At least, no one has addressed how=20 > intermediaries are going to know that this is not an ordinary=20 > REGISTER=20 > request in a way that doesn't effectively make the output of=20 > MARTINI a=20 > mandatory-to-implement part of the core SIP protocol. [JRE] It is not clear to me why intermediaries need to know - it is the SSP= 's domain proxy that needs to know. John >=20 >=20 > > Good grief Adam we are not screwing up the core SIP protocol. What a > > preposterous statement. That was done by others a long time ago. >=20 > "Well, he appears to have a contusion on his leg. Certainly it's okay=20 > break his arm, since he's already injured." >=20 >=20 > > Nor does your solution fix the larger issue of provisioning=20 > between PBX's and SSP. >=20 > If you've read something that you think implied that it did, I assure=20 > you that you've missed the point of whatever you were reading at the=20 > time. Go back and find the intended meaning. >=20 > > IMHO you have not made your case that martini-shaken would=20 > cause any=20 > > damage at all especially since the REGISTER method is very=20 > very widely=20 > > deployed now and actually works .. >=20 > The fact that it works in a specific architecture says=20 > nothing about how=20 > it interacts with other architectures. The proposed changes=20 > to REGISTER=20 > are simply not backwards compatible with the protocol as it=20 > has already=20 > been defined. A change in semantics without an indicator that=20 > will alert=20 > all interested parties of the change in semantics is a recipe for=20 > disaster. And intermediaries are a party to REGISTER=20 > transactions, for=20 > better or for worse. >=20 > /a > = From adam@nostrum.com Thu Jan 7 08:50:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5157A3A6809 for ; Thu, 7 Jan 2010 08:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9n4l27z-872q for ; Thu, 7 Jan 2010 08:50:33 -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 09ED53A63C9 for ; Thu, 7 Jan 2010 08:50:32 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07GoT65013258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 10:50:30 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4610D5.5010204@nostrum.com> Date: Thu, 07 Jan 2010 10:50:29 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:50:34 -0000 On 1/7/10 10:48, Jan 7, Elwell, John wrote: > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 07 January 2010 16:26 >> To: Richard Shockey >> Cc: Elwell, John; martini@ietf.org >> Subject: Re: [martini] draft-roach-martini-up-00 >> >> On 1/7/10 09:55, Jan 7, Richard Shockey wrote: >> >> >>> Adam you are not listing to some of us. >>> >> That's funny -- I get the impression that the key issue I'm raising >> isn't being listened to either. At least, no one has addressed how >> intermediaries are going to know that this is not an ordinary >> REGISTER >> request in a way that doesn't effectively make the output of >> MARTINI a >> mandatory-to-implement part of the core SIP protocol. >> > [JRE] It is not clear to me why intermediaries need to know - it is the SSP's domain proxy that needs to know. > So they can make appropriate policy-related decisions. /a From john.elwell@siemens-enterprise.com Thu Jan 7 08:52:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB5C3A6809 for ; Thu, 7 Jan 2010 08:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 kvU7YvllFB9z for ; Thu, 7 Jan 2010 08:52:03 -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 293B13A63C9 for ; Thu, 7 Jan 2010 08:52:03 -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-467561; Thu, 7 Jan 2010 17:52:01 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4F9B823F0209; Thu, 7 Jan 2010 17:52:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 7 Jan 2010 17:52:01 +0100 From: "Elwell, John" To: Adam Roach Date: Thu, 7 Jan 2010 17:52:00 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPuYg/SxjKxkyyTFu0SOK3dxOOUAAACLnw Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> <4B4610D5.5010204@nostrum.com> In-Reply-To: <4B4610D5.5010204@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:52:04 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 07 January 2010 16:50 > To: Elwell, John > Cc: Richard Shockey; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 10:48, Jan 7, Elwell, John wrote: > > > > > > =20 > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: 07 January 2010 16:26 > >> To: Richard Shockey > >> Cc: Elwell, John; martini@ietf.org > >> Subject: Re: [martini] draft-roach-martini-up-00 > >> > >> On 1/7/10 09:55, Jan 7, Richard Shockey wrote: > >> > >> =20 > >>> Adam you are not listing to some of us. > >>> =20 > >> That's funny -- I get the impression that the key issue I'm raising > >> isn't being listened to either. At least, no one has addressed how > >> intermediaries are going to know that this is not an ordinary > >> REGISTER > >> request in a way that doesn't effectively make the output of > >> MARTINI a > >> mandatory-to-implement part of the core SIP protocol. > >> =20 > > [JRE] It is not clear to me why intermediaries need to know=20 > - it is the SSP's domain proxy that needs to know. > > =20 >=20 > So they can make appropriate policy-related decisions. [JRE] I think Alan just answered that. John >=20 > /a > = From ben@nostrum.com Thu Jan 7 08:59:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC7F03A68C9 for ; Thu, 7 Jan 2010 08:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 DhUTjlyOVMks for ; Thu, 7 Jan 2010 08:59:55 -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 1D9BA3A68B7 for ; Thu, 7 Jan 2010 08:59:54 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-35-178.dsl.rcsntx.swbell.net [68.94.35.178]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07GxpmJ013963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 10:59:51 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Thu, 7 Jan 2010 10:59:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.35.178 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 16:59:56 -0000 John, Do you consider the use of REGISTER to be a _requirement_ for this = effort? That seems like the direction people are going, but I'm not = comfortable with the solution choice being a requirement. I'm not sure I buy the idea that a non-REGISTER solution is necessarily = that much harder to deploy. Face it, even if we end up with a REGISTER = approach, it's going to be somewhere between subtly different and very = different than the approach taken by any particular existing = implementation. At _best_, a small number of implementations luck out in = that their variation gets chosen. It's my experience that implementors will be no more willing to make = small changes than to make bigger ones. Touching anything is the = expensive part, everything else is just work. Also, I don't see how it is any harder for an intermediary device to = recognize it needs to take certain actions with a PUBLISH request with a = certain event header value than it is to recognize it needs to take = certain actions with REGISTER based on a proxy-require, require, or = (heaven-forbid) implicit knowledge of some magic AoR. Adam is correct that bulk register changes the semantics of REGISTER. = The semantic of REGISTER is to bind one or more contacts to a single = AoR. PUBLISH OTOH, was designed with the idea of pushing arbitrary, but = well-defined, state into the network. Bulk-register seems a lot more = like the latter than the former. Full discloser: If I had my druthers, I'd deprecate REGISTER _entirely_, = and replace it with PUBLISH for reg-event or some similar package. = REGISTER is broken even when used according to 3261 (overloaded use of = To, From, and r-URI, pseudo-dialogs, poor concurrency properties, etc.) = We certainly should not be defining _new_ uses of it. On Jan 7, 2010, at 1:42 AM, Elwell, John wrote: > Adam, >=20 > Sure you could specify the use of Path and Service-Route with PUBLISH, = but that is yet another aspect for the entities concerned to support. We = seem to be getting further and further from the objective of fixing the = problem that exists in the field today: lots of implementations based = around REGISTER (+ Path etc.), but differing in details such that = interoperability is impaired. We need to nail down the details so that, = with relatively minor changes to the entities involved, interoperability = can be achieved. The more major the changes, the longer it will take for = vendors to implement, and in fact the less likely it will be that = vendors do implement. >=20 > Furthermore, a simple nailing down of details of how the = REGISTER-based mechanism works might even avoid changes to intermediate = proxies, or at least minimise those changes. A change to PUBLISH with = its entirely new syntax, together with the use of things like Path and = Service-Route with PUBLISH, would represent substantial changes for = those intermediaries. An intermediary would need to behave differently = for a PUBLSIH in accordance with this event package (e.g., add a Path = header field), compared with a PUBLISH for other event packages. Not = very clean >=20 > Finally, I re-iterate that the perceived benefits that the PUBLISH = proposal gives are not requirements. A PBX will generally be configured = or scripted with rules to apply to requests inbound to one if the AORs = it is responsible for, which might include parallel or serial delivery = to multiple contacts, eventual forwarding to voicemail, or in some cases = outright rejection. This information needs to be in the PBX, so that = requests originating in the PBX (or from some other source not arriving = via the SSP) can be handled correctly. Requests arriving from the SSP = should be handled the same (notwithstanding the fact that the rules = concerned might be impacted by the source of the request). The idea is = to deliver requests to the domain that is able to handle them, i.e., the = PBX, and for the PBX to deal with issues of nomadicity etc., e.g., by = redirection if the required contact happens to be off-PBX. The so-called = feature of the SSP being able to fork is in my opinion a disadvantage, > and results in split responsibility for an AOR, something which = surely is contrary to the principles of RFC 3261. >=20 > Note that the multiple registrations capability in the shaken-implicit = draft is intended for resilience purposes, not for being able to = register different contacts for different AORs. >=20 > John >=20 >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com]=20 >> Sent: 07 January 2010 02:01 >> To: Elwell, John >> Cc: martini@ietf.org >> Subject: Re: [martini] draft-roach-martini-up-00 >>=20 >> On 1/6/10 13:56, Jan 6, Elwell, John wrote: >>> Adam, >>>=20 >>> In your proposal, there is no consideration of proxies=20 >> between the PBX and the SSP's domain proxy/registrar, and the=20 >> need for the proxy/registrar to know the path through these=20 >> proxies back to the PBX. In other words, it provides contact=20 >> information without path information. Using the REGISTER=20 >> method, the Path header field solves this problem. >>>=20 >>=20 >> In some rather important ways, that's a feature, not a bug.=20 >> Intermediaries may choose how to handle Path and=20 >> Service-Route based on=20 >> the user being registered. In the case of implicit registrations for=20= >> multiple users, such intermediaries will actually make=20 >> incorrect policy=20 >> decisions, since they'll be basing such decisions on the "To:" header=20= >> field (representing the PBX), not the implicit AORs (representing the=20= >> users). Because intermediaries know what REGISTER means in=20 >> RFC 3261, and=20 >> we're proposing to change that meaning, the only way around this=20 >> particular issue is adding a "Proxy-Require" to implicit=20 >> registrations,=20 >> which is probably not the direction we want to take this. >>=20 >> In terms of how to solve this class of problems with the mechanism I=20= >> propose: it takes a decided lack of imagination not to be able to=20 >> envision how Path and Service-Route could be applied to PUBLISH=20 >> requests. You can get just over 95% of the way there by loading RFCs=20= >> 3327 and 3608 into a text editor and globally replacing the string=20 >> "REGISTER" with "PUBLISH". >>=20 >> /a >>=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Thu Jan 7 09:02:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95D13A6896 for ; Thu, 7 Jan 2010 09:02: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=[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 DPiSKAZEdqQe for ; Thu, 7 Jan 2010 09:02:53 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F22523A681E for ; Thu, 7 Jan 2010 09:02:52 -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, 7 Jan 2010 12:02:49 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 12:02:49 -0500 From: Hadriel Kaplan To: Adam Roach , Richard Shockey Date: Thu, 7 Jan 2010 12:02:47 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPthntH/sBOGylQk68wOybKRX5cAABM1TQ Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> In-Reply-To: <4B460AFA.9010008@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:02:53 -0000 I don't understand this argument. If intermediate proxies need to know, th= ey'll need to know whether we use a REGISTER or a PUBLISH method. It'll be= a Proxy-Require no matter what method name. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Adam Roach > Sent: Thursday, January 07, 2010 11:26 AM >=20 > That's funny -- I get the impression that the key issue I'm raising > isn't being listened to either. At least, no one has addressed how > intermediaries are going to know that this is not an ordinary REGISTER > request in a way that doesn't effectively make the output of MARTINI a > mandatory-to-implement part of the core SIP protocol. >=20 >=20 From drage@alcatel-lucent.com Thu Jan 7 09:03:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD313A6856 for ; Thu, 7 Jan 2010 09:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333, 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 6Fz2xWL-fVVP for ; Thu, 7 Jan 2010 09:03:37 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 37B313A681E for ; Thu, 7 Jan 2010 09:03:37 -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 o07H3YU6020929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 18:03:34 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Jan 2010 18:03:34 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "martini@ietf.org" Date: Thu, 7 Jan 2010 18:03:33 +0100 Thread-Topic: Requirements Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQABL1jA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: 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 Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:03:39 -0000 Most of these I'm happy with. However: > - The mechanism SHOULD scale to PBXs of several thousand users. In my belief the number of users is irrelevant, what we are talking about i= s distinct URIs. Can I also use: > - The mechanism SHOULD require relatively modest changes to a=20 > substantial population of existing SSP and PBX=20 > implementations, in order to encourage a fast market adoption=20 > of the standardized mechanism. to remind all of you that implicit registration is generic to all IMS users= . It is not something that has been crafted especially for PBX attachment, = rather the implicit registration is the same as it has always been. The onl= y change is to allow the implicit registration set to contain this concept = called "wildcarded public user identities". Even that does not need to be s= pecific to PBX attachment as it is merely a means of providing a shorthand = for describing a set of URIs using a single string. The real IMS change specifically there for PBX usage comes in the effect of= the location server / inbound proxy not replacing the request URI when it = finds a registered contact. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, January 07, 2010 4:24 PM > To: martini@ietf.org > Subject: [martini] Requirements >=20 > It has been pointed out to me that the materials for today's=20 > meeting are rather lacking in requirements. Coming up with a=20 > complete set of requirements at short notice is not easy, but=20 > a few of the requirements would be along the following lines.=20 > Perhaps others could help me refine these on the list, so we=20 > have a basis for requirements discussion today. >=20 > - The mechanism MUST allow the PBX to be responsible for its=20 > AORs and to handle requests to those AORs according to its rules. > - The mechanism MUST allow the PBX to receive requests to its=20 > AORs that originate off-PBX and arrive via the SSP, so that=20 > the PBX can handle those requests according to its rules. > - The mechanism MUST provide a means whereby the PBX knows=20 > which of its AORs an inbound request is targeted at.- The=20 > mechanism MUST provide a means of avoiding problems due to=20 > one side using the mechanism when the other side does not=20 > support it or is not using it. > - The mechanism MUST work in the presence of intermediate=20 > "proxies" between the PBX and the SSP's domain proxy, where=20 > those intermediate "proxies" need to be on the path of=20 > inbound requests to the PBX. > - The mechanism MUST work when the PBX obtains its IP address=20 > dynamically. > - The mechanism MUST work without requiring the PBX to=20 > publish reachability information through the DNS. >=20 > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > for providing SIP service to ordinary subscribers in order to=20 > provide a SIP trunking service to PBXs. > - The mechanism SHOULD scale to PBXs of several thousand users. > - The mechanism SHOULD require relatively modest changes to a=20 > substantial population of existing SSP and PBX=20 > implementations, in order to encourage a fast market adoption=20 > of the standardized mechanism. >=20 > John >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From ben@nostrum.com Thu Jan 7 09:09:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745043A6809 for ; Thu, 7 Jan 2010 09:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 E41muL0EASXv for ; Thu, 7 Jan 2010 09:09:31 -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 663753A67FA for ; Thu, 7 Jan 2010 09:09:31 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-35-178.dsl.rcsntx.swbell.net [68.94.35.178]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07H9SJd014762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Jan 2010 11:09:28 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jan 2010 11:09:21 -0600 Message-Id: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> To: martini@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.35.178 is authenticated by a trusted mechanism) Subject: [martini] Provisioning Load X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:09:32 -0000 There's been a lot of discussion that the provisioning load for an SSP = to simply provision routes to each IP-PBX is unacceptable. But if I understand the shaken draft, the SPP will still have to = provision the following information for _each_ pbx: -- The magic one-true AoR, both at the SPP and the PBX. ("One AoR to = bind them...) -- The list of implicit AoRs. (either as a list or some sort of range, = transformation, wildcard, etc) So how does adding "Route to PBX" make things that much worse? It seems = like a fairly small incremental difference. Is it just that the pbx may have an dynamic address?=20 From ben@nostrum.com Thu Jan 7 09:14:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7650A3A687A for ; Thu, 7 Jan 2010 09:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 I8JxLdqmViPa for ; Thu, 7 Jan 2010 09:13:59 -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 02B723A6856 for ; Thu, 7 Jan 2010 09:13:49 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-35-178.dsl.rcsntx.swbell.net [68.94.35.178]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HDjYY015108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 11:13:46 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Thu, 7 Jan 2010 11:13:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9228FD91-D22A-4553-8E5F-979F0769FBEC@nostrum.com> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.35.178 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:14:19 -0000 On Jan 7, 2010, at 11:03 AM, DRAGE, Keith (Keith) wrote: > Can I also use: >=20 >> - The mechanism SHOULD require relatively modest changes to a=20 >> substantial population of existing SSP and PBX=20 >> implementations, in order to encourage a fast market adoption=20 >> of the standardized mechanism. >=20 > to remind all of you that implicit registration is generic to all IMS = users. It is not something that has been crafted especially for PBX = attachment, rather the implicit registration is the same as it has = always been. The only change is to allow the implicit registration set = to contain this concept called "wildcarded public user identities". Even = that does not need to be specific to PBX attachment as it is merely a = means of providing a shorthand for describing a set of URIs using a = single string. >=20 > The real IMS change specifically there for PBX usage comes in the = effect of the location server / inbound proxy not replacing the request = URI when it finds a registered contact. But we're not talking about IMS here. Implicit registration in IMS = solves a very specific IMS problem that is semantically different than = this problem. From adam@nostrum.com Thu Jan 7 09:14:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AFD3A6856 for ; Thu, 7 Jan 2010 09:14: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=[AWL=-0.000, BAYES_00=-2.599, 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 8zshH3uXmsSJ for ; Thu, 7 Jan 2010 09:14:06 -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 10E273A68D0 for ; Thu, 7 Jan 2010 09:14:02 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HDwKs015128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:13:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B461656.5000201@nostrum.com> Date: Thu, 07 Jan 2010 11:13:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080306080407050207080205" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:14:25 -0000 This is a multi-part message in MIME format. --------------080306080407050207080205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This seems like a reasonable set of requirements, although I think our idea of "modest changes" may be subtly different. As Ben points out: "[based on experience], implementors will be no more willing to make small changes than to make bigger ones. Touching anything is the expensive part, everything else is just work." I think it goes as unwritten that we conform to SIP's model of backwards compatibility, so we don't really need to add that to the list. But we do need to keep it in mind. And it actually goes as written that we conform to the SIP Change process. For example: "While interoperability implications can be addressed by capabilities negotiation rules, the effects of adding features that... deal with a point solution and are not general, are much harder to control with rules. Therefore, the RAI Area calls for architectural guardianship and application of Occam's Razor by the SIPCORE and DISPATCH Working Groups." /a On 1/7/10 10:23, Jan 7, Elwell, John wrote: > It has been pointed out to me that the materials for today's meeting are rather lacking in requirements. Coming up with a complete set of requirements at short notice is not easy, but a few of the requirements would be along the following lines. Perhaps others could help me refine these on the list, so we have a basis for requirements discussion today. > > - The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules. > - The mechanism MUST allow the PBX to receive requests to its AORs that originate off-PBX and arrive via the SSP, so that the PBX can handle those requests according to its rules. > - The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at.- The mechanism MUST provide a means of avoiding problems due to one side using the mechanism when the other side does not support it or is not using it. > - The mechanism MUST work in the presence of intermediate "proxies" between the PBX and the SSP's domain proxy, where those intermediate "proxies" need to be on the path of inbound requests to the PBX. > - The mechanism MUST work when the PBX obtains its IP address dynamically. > - The mechanism MUST work without requiring the PBX to publish reachability information through the DNS. > > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing SIP service to ordinary subscribers in order to provide a SIP trunking service to PBXs. > - The mechanism SHOULD scale to PBXs of several thousand users. > - The mechanism SHOULD require relatively modest changes to a substantial population of existing SSP and PBX implementations, in order to encourage a fast market adoption of the standardized mechanism. > > John > > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --------------080306080407050207080205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This seems like a reasonable set of requirements, although I think our idea of "modest changes" may be subtly different. As Ben points out: "[based on experience], implementors will be no more willing to make small changes than to make bigger ones. Touching anything is the expensive part, everything else is just work."

I think it goes as unwritten that we conform to SIP's model of backwards compatibility, so we don't really need to add that to the list. But we do need to keep it in mind.

And it actually goes as written that we conform to the SIP Change process. For example:
"While interoperability implications can be addressed by capabilities negotiation rules, the effects of adding features that... deal with a point solution and are not general, are much harder to control with rules. Therefore, the RAI Area calls for architectural guardianship and application of Occam's Razor by the SIPCORE and DISPATCH Working Groups."

/a

On 1/7/10 10:23, Jan 7, Elwell, John wrote: 
It has been pointed out to me that the materials for today's meeting are rather lacking in requirements. Coming up with a complete set of requirements at short notice is not easy, but a few of the requirements would be along the following lines. Perhaps others could help me refine these on the list, so we have a basis for requirements discussion today.

- The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules.
- The mechanism MUST allow the PBX to receive requests to its AORs that originate off-PBX and arrive via the SSP, so that the PBX can handle those requests according to its rules.
- The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at.- The mechanism MUST provide a means of avoiding problems due to one side using the mechanism when the other side does not support it or is not using it.
- The mechanism MUST work in the presence of intermediate "proxies" between the PBX and the SSP's domain proxy, where those intermediate "proxies" need to be on the path of inbound requests to the PBX.
- The mechanism MUST work when the PBX obtains its IP address dynamically.
- The mechanism MUST work without requiring the PBX to publish reachability information through the DNS.

Also some desiderata:
- The mechanism SHOULD allow SSPs to exploit its mechanisms for providing SIP service to ordinary subscribers in order to provide a SIP trunking service to PBXs.
- The mechanism SHOULD scale to PBXs of several thousand users.
- The mechanism SHOULD require relatively modest changes to a substantial population of existing SSP and PBX implementations, in order to encourage a fast market adoption of the standardized mechanism.

John




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

--------------080306080407050207080205-- From adam@nostrum.com Thu Jan 7 09:16:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCC43A687A for ; Thu, 7 Jan 2010 09:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3KT8cldSBW-P for ; Thu, 7 Jan 2010 09:16: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 271E23A68D3 for ; Thu, 7 Jan 2010 09:16:43 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HGdtc015313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:16:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4616F7.9000104@nostrum.com> Date: Thu, 07 Jan 2010 11:16:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:16:46 -0000 On 1/7/10 11:03, Jan 7, DRAGE, Keith (Keith) wrote: > to remind all of you that implicit registration is generic to all IMS > users. It is not something that has been crafted especially for PBX > attachment, rather the implicit registration is the same as it has > always been. IMS implicit registration deals with a single server, not a batch of disparate users. It's a different operation than is being proposed in the shaken draft. > The only change is to allow the implicit registration set to contain > this concept called "wildcarded public user identities". No. The key change is modifying the semantics to talk about multiple users instead of a single user. /a From adam@nostrum.com Thu Jan 7 09:18:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BA33A6887 for ; Thu, 7 Jan 2010 09:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0Rjjzo8bfTeV for ; Thu, 7 Jan 2010 09:18:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D77B43A687A for ; Thu, 7 Jan 2010 09:18:16 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HIDIx015434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:18:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B461755.8050408@nostrum.com> Date: Thu, 07 Jan 2010 11:18:13 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4B4616F7.9000104@nostrum.com> In-Reply-To: <4B4616F7.9000104@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:18:18 -0000 On 1/7/10 11:16, Jan 7, Adam Roach wrote: > On 1/7/10 11:03, Jan 7, DRAGE, Keith (Keith) wrote: >> to remind all of you that implicit registration is generic to all IMS >> users. It is not something that has been crafted especially for PBX >> attachment, rather the implicit registration is the same as it has >> always been. > > IMS implicit registration deals with a single server, not a batch of > disparate users. It's a different operation than is being proposed in > the shaken draft. That should have said "single user," not "single server." Sorry. /a From ben@nostrum.com Thu Jan 7 09:20:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233973A687A for ; Thu, 7 Jan 2010 09:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Y844dWqmsVcO for ; Thu, 7 Jan 2010 09:20:03 -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 54A2C3A67FA for ; Thu, 7 Jan 2010 09:20:02 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-35-178.dsl.rcsntx.swbell.net [68.94.35.178]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HJs6n015542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jan 2010 11:19:54 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Thu, 7 Jan 2010 11:19:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.35.178 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:20:04 -0000 On Jan 7, 2010, at 11:02 AM, Hadriel Kaplan wrote: >=20 > I don't understand this argument. If intermediate proxies need to = know, they'll need to know whether we use a REGISTER or a PUBLISH = method. It'll be a Proxy-Require no matter what method name. >=20 I think that's the point Adam is was originally tyring to make--the = issue of intermediaries (possibly) needing to know the difference = between normal registers and bulk-registers is made no worse by the use = of PUBLISH than it would be with REGISTER. > -hadriel >=20 >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf >> Of Adam Roach >> Sent: Thursday, January 07, 2010 11:26 AM >>=20 >> That's funny -- I get the impression that the key issue I'm raising >> isn't being listened to either. At least, no one has addressed how >> intermediaries are going to know that this is not an ordinary = REGISTER >> request in a way that doesn't effectively make the output of MARTINI = a >> mandatory-to-implement part of the core SIP protocol. >>=20 >>=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Thu Jan 7 09:23:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C126F3A6856 for ; Thu, 7 Jan 2010 09:23: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, 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 Mh6jNZiglCCc for ; Thu, 7 Jan 2010 09:23:52 -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 628733A6803 for ; Thu, 7 Jan 2010 09:23:52 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HNmcZ015887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:23:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4618A4.8010909@nostrum.com> Date: Thu, 07 Jan 2010 11:23:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090203090107050800070709" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:23:53 -0000 This is a multi-part message in MIME format. --------------090203090107050800070709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: > I don't understand this argument. If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method. It'll be a Proxy-Require no matter what method name. > The key difference is: * With REGISTER, intermediaries unaware of this extension will think they know what the transaction means, and they will be wrong. * With PUBLISH, intermediaries unaware of this extension will either correctly know that the transaction is updating state in the network (if they understand PUBLISH), or they will simply treat it as an unknown transaction type. In both cases, the behavior will be correct. /a --------------090203090107050800070709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: 
I don't understand this argument.  If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method.  It'll be a Proxy-Require no matter what method name.

The key difference is:
  • With REGISTER, intermediaries unaware of this extension will think they know what the transaction means, and they will be wrong.

  • With PUBLISH, intermediaries unaware of this extension will either correctly know that the transaction is updating state in the network (if they understand PUBLISH), or they will simply treat it as an unknown transaction type. In both cases, the behavior will be correct.
/a
--------------090203090107050800070709-- From spencer@wonderhamster.org Thu Jan 7 09:25:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953153A6887 for ; Thu, 7 Jan 2010 09:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=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 Qv49741hgw4a for ; Thu, 7 Jan 2010 09:25:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id ACBAE3A6856 for ; Thu, 7 Jan 2010 09:25:31 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MH1qs-1NfbZU02LK-00EDkf; Thu, 07 Jan 2010 12:25:30 -0500 Message-ID: <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> From: "Spencer Dawkins" To: "Ben Campbell" , "Hadriel Kaplan" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> Date: Thu, 7 Jan 2010 11:25:11 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX181MknDMMEWfec4WYmNjOz15Ub4gI7k48v0Z6k LW2hNJEYmw7Y5iG85RtqHnF0NT+gfEfvK1U57FFIUdZ8PBx4GY PAeeKFThI4O0tq8FIfGSLE7NuoAEUJEC+aXoNgmhZo= Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:25:32 -0000 As a participant... >> I don't understand this argument. If intermediate proxies need to know, >> they'll need to know whether we use a REGISTER or a PUBLISH method. >> It'll be a Proxy-Require no matter what method name. >> > > I think that's the point Adam is was originally tyring to make--the issue > of intermediaries (possibly) needing to know the difference between normal > registers and bulk-registers is made no worse by the use of PUBLISH than > it would be with REGISTER. So, as a reality check ... deployed systems today are using implicit registration with no indication that this is happening in the signaling, but the fact that this isn't visible to intermediaries today wasn't listed in Hadriel's problem statement draft. Is this an oversight? Is anyone encountering problems with intermediaries in deployed systems using implicit registration today? Thanks, Spencer From adam@nostrum.com Thu Jan 7 09:27:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2593A6856 for ; Thu, 7 Jan 2010 09:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xavDDdANxc-U for ; Thu, 7 Jan 2010 09:27:15 -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 39C443A688D for ; Thu, 7 Jan 2010 09:27:15 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HRBov016120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:27:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B46196F.4020006@nostrum.com> Date: Thu, 07 Jan 2010 11:27:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Spencer Dawkins References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> In-Reply-To: <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:27:16 -0000 On 1/7/10 11:25, Jan 7, Spencer Dawkins wrote: > So, as a reality check ... deployed systems today are using implicit > registration with no indication that this is happening in the > signaling, but the fact that this isn't visible to intermediaries > today wasn't listed in Hadriel's problem statement draft. > > Is this an oversight? Is anyone encountering problems with > intermediaries in deployed systems using implicit registration today? The fact that it works in a specific architecture says nothing about how it interacts with other architectures. The proposed changes to REGISTER are simply not backwards compatible with the protocol as it has already been defined. A change in semantics without an indicator that will alert all interested parties of the change in semantics is a recipe for disaster. And intermediaries are a party to REGISTER transactions, for better or for worse. /a From spencer@wonderhamster.org Thu Jan 7 09:37:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5353A681E for ; Thu, 7 Jan 2010 09:37:39 -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 Mm3tdnnt+wcO for ; Thu, 7 Jan 2010 09:37:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4CE3A3A6403 for ; Thu, 7 Jan 2010 09:37:38 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LcAWr-1OAHoE20yj-00j9Vl; Thu, 07 Jan 2010 12:37:36 -0500 Message-ID: <8DA5C68D3EA3429B929650D292F7853E@china.huawei.com> From: "Spencer Dawkins" To: "Adam Roach" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> Date: Thu, 7 Jan 2010 11:37:17 -0600 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: V01U2FsdGVkX19CU6v5AUR84GOIc+5JZLyYM4lguV73l/ygfhK 2SUUR3Yc8CNOm+YI3ewBUTwCURwgOZspQqY77+z0GOn3dDyQAz cmXCFzGEoyffDgQi8RMjGRaVxuLWfs3FNFZ0kf3DA4= Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:37:39 -0000 Hi, Adam, I'm sorry, I wasn't clear. I was asking if it DOES work in a specific architecture :-) Thanks, Spencer >> So, as a reality check ... deployed systems today are using implicit >> registration with no indication that this is happening in the signaling, >> but the fact that this isn't visible to intermediaries today wasn't >> listed in Hadriel's problem statement draft. >> >> Is this an oversight? Is anyone encountering problems with intermediaries >> in deployed systems using implicit registration today? > > The fact that it works in a specific architecture says nothing about how > it interacts with other architectures. The proposed changes to REGISTER > are simply not backwards compatible with the protocol as it has already > been defined. A change in semantics without an indicator that will alert > all interested parties of the change in semantics is a recipe for > disaster. And intermediaries are a party to REGISTER transactions, for > better or for worse. > > /a From adam@nostrum.com Thu Jan 7 09:40:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5103A68D0 for ; Thu, 7 Jan 2010 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4X8IzgLeefDJ for ; Thu, 7 Jan 2010 09:40:56 -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 1BAE73A68D7 for ; Thu, 7 Jan 2010 09:40:55 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07HepC1017273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 11:40:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B461CA3.5070705@nostrum.com> Date: Thu, 07 Jan 2010 11:40:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Spencer Dawkins References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <8DA5C68D3EA3429B929650D292F7853E@china.huawei.com> In-Reply-To: <8DA5C68D3EA3429B929650D292F7853E@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:40:57 -0000 On 1/7/10 11:37, Jan 7, Spencer Dawkins wrote: > Hi, Adam, > > I'm sorry, I wasn't clear. I was asking if it DOES work in a specific > architecture :-) Ah, okay. In that case, I'd reiterate pointing out the sipchange prohibition against point solutions. /a From john.elwell@siemens-enterprise.com Thu Jan 7 09:42:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8663A68D0 for ; Thu, 7 Jan 2010 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC5jN92Uz8F5 for ; Thu, 7 Jan 2010 09:42:06 -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 C2E863A68BC for ; Thu, 7 Jan 2010 09:42:05 -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-468316; Thu, 7 Jan 2010 18:42:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6F03123F0209; Thu, 7 Jan 2010 18:42:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 7 Jan 2010 18:42:03 +0100 From: "Elwell, John" To: Ben Campbell Date: Thu, 7 Jan 2010 18:42:01 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPuta+Hz2+QeECSbWKWkxpn41P/gABRPqw Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> In-Reply-To: <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:42:07 -0000 Ben, > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com]=20 > Sent: 07 January 2010 17:00 > To: Elwell, John > Cc: Adam Roach; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > John, >=20 > Do you consider the use of REGISTER to be a _requirement_ for=20 > this effort? That seems like the direction people are going,=20 > but I'm not comfortable with the solution choice being a requirement. [JRE] Personally I would say it is a requirement, but it would be difficult= to convince everybody. So in that case it is a question of showing that RE= GISTER is as good a solution as any. >=20 > I'm not sure I buy the idea that a non-REGISTER solution is=20 > necessarily that much harder to deploy. Face it, even if we=20 > end up with a REGISTER approach, it's going to be somewhere=20 > between subtly different and very different than the approach=20 > taken by any particular existing implementation. At _best_, a=20 > small number of implementations luck out in that their=20 > variation gets chosen. >=20 > It's my experience that implementors will be no more willing=20 > to make small changes than to make bigger ones. Touching=20 > anything is the expensive part, everything else is just work. >=20 > Also, I don't see how it is any harder for an intermediary=20 > device to recognize it needs to take certain actions with a=20 > PUBLISH request with a certain event header value than it is=20 > to recognize it needs to take certain actions with REGISTER=20 > based on a proxy-require, require, or (heaven-forbid)=20 > implicit knowledge of some magic AoR. [JRE] Nobody has convinced me that an intermediary needs to take special ac= tion beyond what it would do with REGISTER anyway, so the use of Proxy-Requ= ire or whatever should not be necessary. >=20 > Adam is correct that bulk register changes the semantics of=20 > REGISTER. The semantic of REGISTER is to bind one or more=20 > contacts to a single AoR. PUBLISH OTOH, was designed with the=20 > idea of pushing arbitrary, but well-defined, state into the=20 > network. Bulk-register seems a lot more like the latter than=20 > the former. [JRE] I don't think binding a contact to multiple AORs is a big leap from b= inding a contact to a single AOR. >=20 > Full discloser: If I had my druthers, I'd deprecate REGISTER=20 > _entirely_, and replace it with PUBLISH for reg-event or some=20 > similar package. REGISTER is broken even when used according=20 > to 3261 (overloaded use of To, From, and r-URI,=20 > pseudo-dialogs, poor concurrency properties, etc.) We=20 > certainly should not be defining _new_ uses of it. [JRE] Yes, perhaps REGISTER is broken anyway, but it is still a fundamental= part of SIP. I believe we can easily fix it to accomplish the present task= . John >=20 >=20 > On Jan 7, 2010, at 1:42 AM, Elwell, John wrote: >=20 > > Adam, > >=20 > > Sure you could specify the use of Path and Service-Route=20 > with PUBLISH, but that is yet another aspect for the entities=20 > concerned to support. We seem to be getting further and=20 > further from the objective of fixing the problem that exists=20 > in the field today: lots of implementations based around=20 > REGISTER (+ Path etc.), but differing in details such that=20 > interoperability is impaired. We need to nail down the=20 > details so that, with relatively minor changes to the=20 > entities involved, interoperability can be achieved. The more=20 > major the changes, the longer it will take for vendors to=20 > implement, and in fact the less likely it will be that=20 > vendors do implement. > >=20 > > Furthermore, a simple nailing down of details of how the=20 > REGISTER-based mechanism works might even avoid changes to=20 > intermediate proxies, or at least minimise those changes. A=20 > change to PUBLISH with its entirely new syntax, together with=20 > the use of things like Path and Service-Route with PUBLISH,=20 > would represent substantial changes for those intermediaries.=20 > An intermediary would need to behave differently for a=20 > PUBLSIH in accordance with this event package (e.g., add a=20 > Path header field), compared with a PUBLISH for other event=20 > packages. Not very clean > >=20 > > Finally, I re-iterate that the perceived benefits that the=20 > PUBLISH proposal gives are not requirements. A PBX will=20 > generally be configured or scripted with rules to apply to=20 > requests inbound to one if the AORs it is responsible for,=20 > which might include parallel or serial delivery to multiple=20 > contacts, eventual forwarding to voicemail, or in some cases=20 > outright rejection. This information needs to be in the PBX,=20 > so that requests originating in the PBX (or from some other=20 > source not arriving via the SSP) can be handled correctly.=20 > Requests arriving from the SSP should be handled the same=20 > (notwithstanding the fact that the rules concerned might be=20 > impacted by the source of the request). The idea is to=20 > deliver requests to the domain that is able to handle them,=20 > i.e., the PBX, and for the PBX to deal with issues of=20 > nomadicity etc., e.g., by redirection if the required contact=20 > happens to be off-PBX. The so-called feature of the SSP being=20 > able to fork is in my opinion a disadvantage, > > and results in split responsibility for an AOR, something=20 > which surely is contrary to the principles of RFC 3261. > >=20 > > Note that the multiple registrations capability in the=20 > shaken-implicit draft is intended for resilience purposes,=20 > not for being able to register different contacts for different AORs. > >=20 > > John > >=20 > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com]=20 > >> Sent: 07 January 2010 02:01 > >> To: Elwell, John > >> Cc: martini@ietf.org > >> Subject: Re: [martini] draft-roach-martini-up-00 > >>=20 > >> On 1/6/10 13:56, Jan 6, Elwell, John wrote: > >>> Adam, > >>>=20 > >>> In your proposal, there is no consideration of proxies=20 > >> between the PBX and the SSP's domain proxy/registrar, and the=20 > >> need for the proxy/registrar to know the path through these=20 > >> proxies back to the PBX. In other words, it provides contact=20 > >> information without path information. Using the REGISTER=20 > >> method, the Path header field solves this problem. > >>>=20 > >>=20 > >> In some rather important ways, that's a feature, not a bug.=20 > >> Intermediaries may choose how to handle Path and=20 > >> Service-Route based on=20 > >> the user being registered. In the case of implicit=20 > registrations for=20 > >> multiple users, such intermediaries will actually make=20 > >> incorrect policy=20 > >> decisions, since they'll be basing such decisions on the=20 > "To:" header=20 > >> field (representing the PBX), not the implicit AORs=20 > (representing the=20 > >> users). Because intermediaries know what REGISTER means in=20 > >> RFC 3261, and=20 > >> we're proposing to change that meaning, the only way around this=20 > >> particular issue is adding a "Proxy-Require" to implicit=20 > >> registrations,=20 > >> which is probably not the direction we want to take this. > >>=20 > >> In terms of how to solve this class of problems with the=20 > mechanism I=20 > >> propose: it takes a decided lack of imagination not to be able to=20 > >> envision how Path and Service-Route could be applied to PUBLISH=20 > >> requests. You can get just over 95% of the way there by=20 > loading RFCs=20 > >> 3327 and 3608 into a text editor and globally replacing the string=20 > >> "REGISTER" with "PUBLISH". > >>=20 > >> /a > >>=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > = From pkyzivat@cisco.com Thu Jan 7 09:49:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A595B3A68DD for ; Thu, 7 Jan 2010 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.195 X-Spam-Level: X-Spam-Status: No, score=-10.195 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWMu8kEYR+Yj for ; Thu, 7 Jan 2010 09:49:56 -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 BA5E23A67F8 for ; Thu, 7 Jan 2010 09:49:55 -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: ApoEAA+uRUutJV2Y/2dsb2JhbADBHZN9hDAE X-IronPort-AV: E=Sophos;i="4.49,236,1262563200"; d="scan'208";a="78802195" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2010 17:49:53 +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 o07HnrVD003103; Thu, 7 Jan 2010 17:49:53 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 11:49:53 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 11:49:53 -0600 Message-ID: <4B461EBB.90605@cisco.com> Date: Thu, 07 Jan 2010 12:49:47 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jan 2010 17:49:53.0111 (UTC) FILETIME=[D0FBE670:01CA8FC1] Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:49:56 -0000 Elwell, John wrote: >> Adam is correct that bulk register changes the semantics of >> REGISTER. The semantic of REGISTER is to bind one or more >> contacts to a single AoR. PUBLISH OTOH, was designed with the >> idea of pushing arbitrary, but well-defined, state into the >> network. Bulk-register seems a lot more like the latter than >> the former. > [JRE] I don't think binding a contact to multiple AORs is a big leap from binding a contact to a single AOR. To an extent I agree with John here. IMO the implicit registration that IMS is doing is a larger violation of the semantics of REGISTER. But nobody ever asked if that was ok, and now it seems that everyone considers it to be grandfathered in even though there no IETF spec defining it. Thanks, Paul From BLINDSAY@nortel.com Thu Jan 7 09:55:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A742C3A68DD for ; Thu, 7 Jan 2010 09:55:43 -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 0Ouce2JSDLqk for ; Thu, 7 Jan 2010 09:55:42 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A1CB33A68D8 for ; Thu, 7 Jan 2010 09:55:42 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o07Ht5100919; Thu, 7 Jan 2010 17:55:06 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jan 2010 12:54:56 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C003A6F@zcarhxm1.corp.nortel.com> In-Reply-To: <4B461755.8050408@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements Thread-Index: AcqPvW3Oanx2NbzSQSe06oe8bhxEzQAAVzqw References: <4B4616F7.9000104@nostrum.com> <4B461755.8050408@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" , "DRAGE, Keith (Keith)" Cc: martini@ietf.org Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:55:43 -0000 Hi, I don't think it's really fundamentally different in the context of how 3GPP/TISPAN support SIP PBXs in what they term "subscrption mode". 3GPP/IMS support for SIP PBXs was driven by work originally done by TISPAN. TISPAN has the concept of a "Next Generation Corporate Network (NGCN) Site Identifier", which is basically an AoR representing the SIP PBX, and which is the used in the registration request from the SIP PBX to the network. It's basically analagous to the explicit registration AoR in the Martini-shaken draft. Like in Martini-shaken, TISPAN/3GPP use implicit registration for the set of AoRs associated with the SIP PBX users, and for requests routed to the SIP PBX, the request uri is not overwritten with the registration contact. I believe the big difference in Martini-shaken is some of the new proposed option tags and header fields being added. =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, January 07, 2010 12:18 PM To: DRAGE, Keith (Keith) Cc: martini@ietf.org Subject: Re: [martini] Requirements On 1/7/10 11:16, Jan 7, Adam Roach wrote: > On 1/7/10 11:03, Jan 7, DRAGE, Keith (Keith) wrote: >> to remind all of you that implicit registration is generic to all IMS >> users. It is not something that has been crafted especially for PBX=20 >> attachment, rather the implicit registration is the same as it has=20 >> always been. > > IMS implicit registration deals with a single server, not a batch of=20 > disparate users. It's a different operation than is being proposed in=20 > the shaken draft. That should have said "single user," not "single server." Sorry. /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bruno.chatras@orange-ftgroup.com Thu Jan 7 09:58:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1455E3A68D8 for ; Thu, 7 Jan 2010 09:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 SyC9AwYrrS3z for ; Thu, 7 Jan 2010 09:58:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id D44013A68B8 for ; Thu, 7 Jan 2010 09:58:53 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 83F7A3B4168; Thu, 7 Jan 2010 18:58:51 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6324715805C; Thu, 7 Jan 2010 18:58:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 18:58: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: Thu, 7 Jan 2010 18:58:47 +0100 Message-ID: <11413_1262887128_4B4620D8_11413_60866_1_9ECCF01B52E7AB408A7EB85352642141EA1269@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B460EFA.9000307@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPuJS+De8ik3m1R6mJTY2MGQqQywACIvXg References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> <4B460EFA.9000307@nostrum.com> From: To: X-OriginalArrivalTime: 07 Jan 2010 17:58:49.0029 (UTC) FILETIME=[106A7F50:01CA8FC3] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.7.161819 Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 17:58:55 -0000 =20 > -----Message d'origine----- > De : Adam Roach [mailto:adam@nostrum.com]=20 > Envoy=E9 : jeudi 7 janvier 2010 17:43 > =C0 : CHATRAS Bruno RD-CORE-ISS > Cc : john.elwell@siemens-enterprise.com; martini@ietf.org > Objet : Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 10:28, Jan 7, bruno.chatras@orange-ftgroup.com wrote: > > I'm not sure I understand why using REGISTER for the PBX=20 > case is fundamentally broken. >=20 > Consider the case in which the intermediary is making policy=20 > decisions based on the user being registered. If it uses the=20 > RFC 3261 definition of REGISTER, then it knows that the user=20 > under discussion is the user indicated in the "To" header=20 > field, and that policies should be applied accordingly. >=20 > Once we change the semantics of REGISTER so that the user --=20 > or users -- under discussion no longer appear in the "To"=20 > header field, then this intermediary will be relying on=20 > incorrect information for its policies. =3D=3D>BC: I don't see any concrete issue here. Policy decisions made by an= intermediary would typically depend on the SLA between the SIP Service Pro= vider and the enterprise (hence the identity in the To header of the REGIST= ER request) rather than on individual enterprise members. >=20 >=20 > > Is there a fundamental difference between a small PBX and a=20 > SIP-aware Home/Residential Gateway serving a couple of=20 > lines/numbers/users in one house? Or would you also argue=20 > that such a HGW should also use the PUBLISH method? > >=20=20=20=20 >=20 > I would argue that a small home gateway servicing two users=20 > would generally maintain two independent registrations using=20 > the REGISTER method. >=20 > However, if they wanted to consolidate these into a single=20 > operation, then yes, the idea is that the unified way to=20 > update rendezvous information for multiple users would be=20 > using PUBLISH. =3D=3D>BC: I believe a Home Gateway conforming to the Home Gateway Initiati= ve specifications would use a REGISTER message in all cases. >=20 > /a >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Thu Jan 7 10:01:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53353A68B8 for ; Thu, 7 Jan 2010 10:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qu0BLw3n76Y4 for ; Thu, 7 Jan 2010 10:01:05 -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 BD36928C0DB for ; Thu, 7 Jan 2010 10:01:02 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07I0xVm018863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 12:00:59 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B46215B.1010105@nostrum.com> Date: Thu, 07 Jan 2010 12:00:59 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> <4B460EFA.9000307@nostrum.com> <11413_1262887128_4B4620D8_11413_60866_1_9ECCF01B52E7AB408A7EB85352642141EA1269@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <11413_1262887128_4B4620D8_11413_60866_1_9ECCF01B52E7AB408A7EB85352642141EA1269@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:01:05 -0000 On 1/7/10 11:58, Jan 7, bruno.chatras@orange-ftgroup.com wrote: > -----Message d'origine----- >> De : Adam Roach [mailto:adam@nostrum.com] >> Envoyé : jeudi 7 janvier 2010 17:43 >> À : CHATRAS Bruno RD-CORE-ISS >> Cc : john.elwell@siemens-enterprise.com; martini@ietf.org >> Objet : Re: [martini] draft-roach-martini-up-00 >> >> On 1/7/10 10:28, Jan 7, bruno.chatras@orange-ftgroup.com wrote: >> >>> I'm not sure I understand why using REGISTER for the PBX >>> >> case is fundamentally broken. >> >> Consider the case in which the intermediary is making policy >> decisions based on the user being registered. If it uses the >> RFC 3261 definition of REGISTER, then it knows that the user >> under discussion is the user indicated in the "To" header >> field, and that policies should be applied accordingly. >> >> Once we change the semantics of REGISTER so that the user -- >> or users -- under discussion no longer appear in the "To" >> header field, then this intermediary will be relying on >> incorrect information for its policies. >> > ==>BC: I don't see any concrete issue here. Policy decisions made by an intermediary would typically depend on the SLA between the SIP Service Provider and the enterprise (hence the identity in the To header of the REGISTER request) rather than on individual enterprise members. > For the specific architecture you have in mind, yes. I'm concerned about the broader picture. /a From drage@alcatel-lucent.com Thu Jan 7 10:05:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D3A43A6856 for ; Thu, 7 Jan 2010 10:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.106 X-Spam-Level: X-Spam-Status: No, score=-3.106 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 5nYz3TuoyCAB for ; Thu, 7 Jan 2010 10:05:01 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 27CD13A68FB for ; Thu, 7 Jan 2010 10:05:00 -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 o07I4uxu026837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 19:04:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 7 Jan 2010 19:04:56 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , "bruno.chatras@orange-ftgroup.com" Date: Thu, 7 Jan 2010 19:04:54 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPuHUsVU/oFWVdRJaQ3WyniPSuFQACzINQ Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <26212_1262881695_4B460B9F_26212_3095_1_9ECCF01B52E7AB408A7EB85352642141EA11B3@ftrdmel0.rd.francetelecom.fr> <4B460EFA.9000307@nostrum.com> In-Reply-To: <4B460EFA.9000307@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:05:02 -0000 At the point we are talking about, any policy decisions should be on the PB= X operator as a whole - applying them to individual users on the PBX is fun= damentally broken. If nothing else because you are going to get outgoing ca= lls appearing across this interface that are not normally hosted on this in= terface where one has a network of PBXs routing internally before sending t= o the public network. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Thursday, January 07, 2010 4:43 PM > To: bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 10:28, Jan 7, bruno.chatras@orange-ftgroup.com wrote: > > I'm not sure I understand why using REGISTER for the PBX=20 > case is fundamentally broken. >=20 > Consider the case in which the intermediary is making policy=20 > decisions based on the user being registered. If it uses the=20 > RFC 3261 definition of REGISTER, then it knows that the user=20 > under discussion is the user indicated in the "To" header=20 > field, and that policies should be applied accordingly. >=20 > Once we change the semantics of REGISTER so that the user --=20 > or users -- under discussion no longer appear in the "To"=20 > header field, then this intermediary will be relying on=20 > incorrect information for its policies. >=20 >=20 > > Is there a fundamental difference between a small PBX and a=20 > SIP-aware Home/Residential Gateway serving a couple of=20 > lines/numbers/users in one house? Or would you also argue=20 > that such a HGW should also use the PUBLISH method? > > =20 >=20 > I would argue that a small home gateway servicing two users=20 > would generally maintain two independent registrations using=20 > the REGISTER method. >=20 > However, if they wanted to consolidate these into a single=20 > operation, then yes, the idea is that the unified way to=20 > update rendezvous information for multiple users would be=20 > using PUBLISH. >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From richard@shockey.us Thu Jan 7 10:15:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F00728C0DB for ; Thu, 7 Jan 2010 10:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.836 X-Spam-Level: X-Spam-Status: No, score=-0.836 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_05=-1.11, 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 AoVjmB7elPeM for ; Thu, 7 Jan 2010 10:15:16 -0800 (PST) Received: from outbound-mail-39.bluehost.com (outbound-mail-39.bluehost.com [69.89.20.193]) by core3.amsl.com (Postfix) with SMTP id 8E8AD3A68DD for ; Thu, 7 Jan 2010 10:15:16 -0800 (PST) Received: (qmail 18690 invoked by uid 0); 7 Jan 2010 18:15:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 7 Jan 2010 18:15:13 -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=CsJ8wxhAQcFP8f5ppnYoJHRKQeIq0qRaKHRLwZur5RxN/7kbETfe7fMGDnzsCcS8doSS5ZD6v/5FbnOKe+MZD4eEeXmJK8AnMNp+lcFci7nxeOLN5VbHYe3oou4irgFg; 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 1NSwt6-0001d1-RL; Thu, 07 Jan 2010 11:15:13 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> <4B461EBB.90605@cisco.com> In-Reply-To: <4B461EBB.90605@cisco.com> Date: Thu, 7 Jan 2010 13:15:04 -0500 Message-ID: <011201ca8fc5$56adf210$0409d630$@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: AcqPwdPlEWdesGQ+RROkX1OeSxCVaQAAUzjg 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} Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:15:21 -0000 Below .. > >> Adam is correct that bulk register changes the semantics of > >> REGISTER. The semantic of REGISTER is to bind one or more > >> contacts to a single AoR. PUBLISH OTOH, was designed with the > >> idea of pushing arbitrary, but well-defined, state into the > >> network. Bulk-register seems a lot more like the latter than > >> the former. > > [JRE] I don't think binding a contact to multiple AORs is a big leap > from binding a contact to a single AOR. Right .. > > To an extent I agree with John here. > IMO the implicit registration that IMS is doing is a larger violation > of the semantics of REGISTER. But nobody ever asked if that was ok, and > now it seems that everyone considers it to be grandfathered in even though > there no IETF spec defining it. Paul that is a reasonable summary of how we got here. It slipped through several layers of cracks in the IETF and 3GPP process. It's there in the field, in large deployments and pretty well entrenched especially in smaller systems. The preference of some of us is to make the technique a bit more defined in order to deal with some of the interoperability issues its caused. IMO trying to define an entirely new registration procedure using PUBLISH could cause serious disruption in the market place and may not even be adopted due the existing grandfathered base. Sure ..there is a reasonable technical case for using a PUBLISH methodology for this class of AOR registration but the business case for using REGISTER with a option tag is overwhelming. From adam@nostrum.com Thu Jan 7 10:26:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1BF3A68FB for ; Thu, 7 Jan 2010 10:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 dl2xlf+vLNlG for ; Thu, 7 Jan 2010 10:26:35 -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 1230B3A6855 for ; Thu, 7 Jan 2010 10:26:34 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07IQSYm020796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 12:26:28 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B462753.2080903@nostrum.com> Date: Thu, 07 Jan 2010 12:26:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Richard Shockey References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <2EFD69C3-3CBD-42C5-A5F7-9B1F82DB0910@nostrum.com> <4B461EBB.90605@cisco.com> <011201ca8fc5$56adf210$0409d630$@us> In-Reply-To: <011201ca8fc5$56adf210$0409d630$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:26:36 -0000 On 1/7/10 12:15, Jan 7, Richard Shockey wrote: > Paul that is a reasonable summary of how we got here. It slipped through > several layers of cracks in the IETF and 3GPP process. It's there in the > field, in large deployments and pretty well entrenched especially in smaller > systems. The preference of some of us is to make the technique a bit more > defined in order to deal with some of the interoperability issues its > caused. > > IMO trying to define an entirely new registration procedure using PUBLISH > could cause serious disruption in the market place and may not even be > adopted due the existing grandfathered base. > > Sure ..there is a reasonable technical case for using a PUBLISH methodology > for this class of AOR registration but the business case for using REGISTER > with a option tag is overwhelming. > So, you're pretty much saying that we should have chartered as "Retroactively Updating Bygones By Extending REGISTER So That Architectures gEt Pulverized", or "RUBBERSTAMP"? /a From adam@nostrum.com Thu Jan 7 10:29:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6583A68D7 for ; Thu, 7 Jan 2010 10:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lUWDwg8cWhqD for ; Thu, 7 Jan 2010 10:29:56 -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 EC0F13A6855 for ; Thu, 7 Jan 2010 10:29:55 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07ITqxc021028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 12:29:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B462820.4010702@nostrum.com> Date: Thu, 07 Jan 2010 12:29:52 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Alan Johnston References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> In-Reply-To: <4B46102F.9000006@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:29:57 -0000 On 1/7/10 10:47, Jan 7, Alan Johnston wrote: > What kinds of sensible things could an intermediary proxy do with such > a REGISTER? And what problems would this cause? > > I could only imagine a proxy which is part of either the service > provider domain or the enterprise domain doing anything sensible with > the REGISTER, and both of these would recognize it as as what it is. Yes, for the large part, the architectures people are _currently_ looking at will be limited to these two situations. And, for those architectures, your assertion holds. Here's the issue I have: SIP is designed to be an extensible, flexible protocol that can be used for arbitrary architectures. That design is intended to foster innovation, instead of locking down the network architecture into a small set of blessed configurations. If we take actions that preclude certain architectures -- even if we can't design those architectures right now -- then we limit SIP's flexibility. We constrain innovation. Certainly we're not hubristic enough to think that we can predict all possible useful architectures. But we can at least identify where inherent aspects of the protocol are being modified, and avoid doing them in an incompatible fashion. /a From D.Hancock@CableLabs.com Thu Jan 7 10:35:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217C43A68FB for ; Thu, 7 Jan 2010 10:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQk1dqo2vexI for ; Thu, 7 Jan 2010 10:35:22 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 2A9E13A67A5 for ; Thu, 7 Jan 2010 10:35:22 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id o07IZJml004773; Thu, 7 Jan 2010 11:35:20 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 7 Jan 2010 11:35:19 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jan 2010 11:35:19 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60278F46F@srvxchg3.cablelabs.com> In-Reply-To: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Provisioning Load Thread-Index: AcqPvC8+npd9LDN+T1mIgYKfFGztLgABKYcA References: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> From: "David Hancock" To: "Ben Campbell" , X-Approved: ondar Subject: Re: [martini] Provisioning Load X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:35:23 -0000 Ben, The advantage I see to establishing the path at registration time is that it allows the routing path itself to be dynamic. If a Service Provider proxy in the current routing path fails, the IP-PBX registers anew, establishing a new path.=20 Thanks David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Ben Campbell > Sent: Thursday, January 07, 2010 10:09 AM > To: martini@ietf.org > Subject: [martini] Provisioning Load >=20 > There's been a lot of discussion that the provisioning load for an SSP to > simply provision routes to each IP-PBX is unacceptable. >=20 > But if I understand the shaken draft, the SPP will still have to provision > the following information for _each_ pbx: >=20 > -- The magic one-true AoR, both at the SPP and the PBX. ("One AoR to bind > them...) > -- The list of implicit AoRs. (either as a list or some sort of range, > transformation, wildcard, etc) >=20 > So how does adding "Route to PBX" make things that much worse? It seems > like a fairly small incremental difference. >=20 > Is it just that the pbx may have an dynamic address? >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Thu Jan 7 10:38:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076E63A6908 for ; Thu, 7 Jan 2010 10:38:32 -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 maVx46wFRy+W for ; Thu, 7 Jan 2010 10:38:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 39EBD3A6902 for ; Thu, 7 Jan 2010 10:38:31 -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, 7 Jan 2010 13:38:27 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 13:38:27 -0500 From: Hadriel Kaplan To: Spencer Dawkins , Ben Campbell Date: Thu, 7 Jan 2010 13:38:26 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvnVoPVxgnVIyQueDgbI6u5nxvQACezJw Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> In-Reply-To: <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.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: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:38:32 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Thursday, January 07, 2010 12:25 PM >=20 > So, as a reality check ... deployed systems today are using implicit > registration with no indication that this is happening in the signaling, > but > the fact that this isn't visible to intermediaries today wasn't listed in > Hadriel's problem statement draft. Umm, yes I did. The lack of an explicit indication is listed in the doc, a= s is the issue that intermediaries need one. -hadriel From HKaplan@acmepacket.com Thu Jan 7 10:41:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA27128C0F1 for ; Thu, 7 Jan 2010 10:41:44 -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, 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 tBe2jN92b3zh for ; Thu, 7 Jan 2010 10:41:40 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A6DED28C13D for ; Thu, 7 Jan 2010 10:41: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, 7 Jan 2010 13:41:38 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 13:41:38 -0500 From: Hadriel Kaplan To: Adam Roach Date: Thu, 7 Jan 2010 13:41:37 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvknzEM1UEad0R86xRKk1BaAmCgAClU1g Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> <4B4618A4.8010909@nostrum.com> In-Reply-To: <4B4618A4.8010909@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A587433AFmail_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:41:45 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A587433AFmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, January 07, 2010 12:24 PM To: Hadriel Kaplan Cc: Richard Shockey; martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: I don't understand this argument. If intermediate proxies need to know, th= ey'll need to know whether we use a REGISTER or a PUBLISH method. It'll be= a Proxy-Require no matter what method name. The key difference is: * With REGISTER, intermediaries unaware of this extension will think the= y know what the transaction means, and they will be wrong. No they won't. Draft shaken and stirred both ask for a new option-tag. Ri= ght now they only mention putting them in the Require, but if the WG decide= s it's necessary in Proxy-Require too that's not exactly a big leap. * With PUBLISH, intermediaries unaware of this extension will either cor= rectly know that the transaction is updating state in the network (if they = understand PUBLISH), or they will simply treat it as an unknown transaction= type. In both cases, the behavior will be correct. If I'm a "proxy" today with specific policies tied around Registrations, I = don't necessarily need to understand anything special about PUBLISH today. = So just using the PUBLISH method does not automagically work. We'll need = a proxy-require. --_000_E6C2E8958BA59A4FB960963D475F7AC31A587433AFmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, January 07, = 2010 12:24 PM
To: Hadriel Kaplan
Cc: Richard Shockey; martini@ietf.org
Subject: Re: [martini] draft-roach-martini-up-00

=  

= On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: 

 
I don't understand this argument.  If intermediate proxies need to k=
now, they'll need to know whether we use a REGISTER or a PUBLISH method.&nb=
sp; It'll be a Proxy-Require no matter what method name.<=
/font>
 

=
The key difference is:

  • With REGISTER, intermediaries unaware of th= is extension will think they know what the transaction means, and they wi= ll be wrong.

No they won’t.  Draft shaken and stirred both ask fo= r a new option-tag.  Right now they only mention putting them in the Require, = but if the WG decides it’s necessary in Proxy-Require too that’s not exactly a big leap.

  • With PUBLISH, intermediaries unaware of thi= s extension will either correctly know that the transaction is updating state in the network (if they understand PUBLISH), or they will simply treat it as an unknown transaction type. In both cases, the behavior w= ill be correct.

<= span style=3D'font-size:12.0pt;color:navy'>If I’m a “proxy” to= day with specific policies tied around Registrations, I don’t necessarily need to understand anything special about PUBLISH today.  So just usin= g the PUBLISH method does not automagically work.  We’ll need a proxy-= require.

--_000_E6C2E8958BA59A4FB960963D475F7AC31A587433AFmail_-- From drage@alcatel-lucent.com Thu Jan 7 10:42:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D8A3A6902 for ; Thu, 7 Jan 2010 10:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.250, 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 2m070mo-dasW for ; Thu, 7 Jan 2010 10:42:51 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 706B428C12D for ; Thu, 7 Jan 2010 10:42:51 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o07IgmCw014393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 19:42:48 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 7 Jan 2010 19:42:48 +0100 From: "DRAGE, Keith (Keith)" To: Ben Campbell , "martini@ietf.org" Date: Thu, 7 Jan 2010 19:42:46 +0100 Thread-Topic: [martini] Provisioning Load Thread-Index: AcqPvDDvp6OWHFj6RuucfohOaWxi5QADJbWQ Message-ID: References: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> In-Reply-To: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [martini] Provisioning Load X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:42:52 -0000 At least for IMS, it means that there is one user record in the SPP databas= e, rather than one for each URI. Given that all those records, if separate,= would essentially need the same information, that is the saving to the ope= rator in terms of provisioning time. Of course you could always argue that all these duplicate records could be = created by some sort of intelligent front end, but ... Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, January 07, 2010 5:09 PM > To: martini@ietf.org > Subject: [martini] Provisioning Load >=20 > There's been a lot of discussion that the provisioning load=20 > for an SSP to simply provision routes to each IP-PBX is unacceptable. >=20 > But if I understand the shaken draft, the SPP will still have=20 > to provision the following information for _each_ pbx: >=20 > -- The magic one-true AoR, both at the SPP and the PBX. ("One=20 > AoR to bind them...) > -- The list of implicit AoRs. (either as a list or some sort=20 > of range, transformation, wildcard, etc) >=20 > So how does adding "Route to PBX" make things that much=20 > worse? It seems like a fairly small incremental difference. >=20 > Is it just that the pbx may have an dynamic address?=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From spencer@wonderhamster.org Thu Jan 7 10:42:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD40D3A6902 for ; Thu, 7 Jan 2010 10:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=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 qy8sIDuqB88v for ; Thu, 7 Jan 2010 10:42:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id E88F43A6904 for ; Thu, 7 Jan 2010 10:42:55 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lh8ff-1OE6Ep2go3-00o53c; Thu, 07 Jan 2010 13:42:52 -0500 Message-ID: <99CE263A0C8C493CABD6EF2E4D010748@china.huawei.com> From: "Spencer Dawkins" To: "Hadriel Kaplan" , "Ben Campbell" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> Date: Thu, 7 Jan 2010 12:42:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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/X4AAxAZ8a0T5+5tyHdBXODUMllLZZZRVmrsm lMsHeCCbEbrTstT2GBA3J93hRs5aEduZcuxeaOzGPKqgzhM+gj lVpy9IWZP0Dbb6KfekoGkcco7n+LR/2DkIMqrRLGmM= Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:42:56 -0000 Hi, Hadriel, Sorry I missed it! I apparently jumped from the first paragraph to the third paragraph in 4.1 of the problem statement. The second paragraph answered my question. And thanks for pointing it out. Spencer ----- Original Message ----- From: "Hadriel Kaplan" To: "Spencer Dawkins" ; "Ben Campbell" Cc: Sent: Thursday, January 07, 2010 12:38 PM Subject: RE: [martini] draft-roach-martini-up-00 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Spencer Dawkins > Sent: Thursday, January 07, 2010 12:25 PM > > So, as a reality check ... deployed systems today are using implicit > registration with no indication that this is happening in the signaling, > but > the fact that this isn't visible to intermediaries today wasn't listed in > Hadriel's problem statement draft. Umm, yes I did. The lack of an explicit indication is listed in the doc, as is the issue that intermediaries need one. -hadriel From drage@alcatel-lucent.com Thu Jan 7 10:44:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165C528C12D for ; Thu, 7 Jan 2010 10:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-0.889, 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 PGH-SpzlS75W for ; Thu, 7 Jan 2010 10:44:55 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 0882828C0F1 for ; Thu, 7 Jan 2010 10:44:54 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o07Iiq7W030553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 19:44:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 7 Jan 2010 19:44:52 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Thu, 7 Jan 2010 19:44:50 +0100 Thread-Topic: [martini] Requirements Thread-Index: AcqPvTLRdm2FhEN5QhmJKMP4enEh0AADCBJw Message-ID: References: <4B4616F7.9000104@nostrum.com> In-Reply-To: <4B4616F7.9000104@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:44:56 -0000 And you are arguing for a concept of "user" within the SSP which I say is r= edundant.=20 I repeat again, the SSP needs to know about its relationship with the PBX o= perator, not the set of users that may be hosted on the PBX - that is the r= esponsibility of the PBX operator. Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Thursday, January 07, 2010 5:17 PM > To: DRAGE, Keith (Keith) > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements >=20 > On 1/7/10 11:03, Jan 7, DRAGE, Keith (Keith) wrote: > > to remind all of you that implicit registration is generic=20 > to all IMS=20 > > users. It is not something that has been crafted especially for PBX=20 > > attachment, rather the implicit registration is the same as it has=20 > > always been. >=20 > IMS implicit registration deals with a single server, not a=20 > batch of disparate users. It's a different operation than is=20 > being proposed in the shaken draft. >=20 > > The only change is to allow the implicit registration set=20 > to contain=20 > > this concept called "wildcarded public user identities". >=20 > No. The key change is modifying the semantics to talk about=20 > multiple users instead of a single user. >=20 > /a > = From drage@alcatel-lucent.com Thu Jan 7 10:47:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8833A690F for ; Thu, 7 Jan 2010 10:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.049 X-Spam-Level: X-Spam-Status: No, score=-5.049 tagged_above=-999 required=5 tests=[AWL=1.200, 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 dwlbYCga27zn for ; Thu, 7 Jan 2010 10:47:22 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id E66E63A6902 for ; Thu, 7 Jan 2010 10:47:21 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o07IlG0o015189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Jan 2010 19:47:17 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 7 Jan 2010 19:47:16 +0100 From: "DRAGE, Keith (Keith)" To: Spencer Dawkins , Ben Campbell , Hadriel Kaplan Date: Thu, 7 Jan 2010 19:47:14 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvm3IMW4YDuYsQRSiWHpHVxQuxQACzaBw Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> In-Reply-To: <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.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: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:47:23 -0000 That will also be one of my questions on the call. IMS has been using implicit registration since 2002. No one has identified = any interoperability issues in the fora I attend with this. So I would like some specifics as to what interoperability issues the use o= f implicit registration is understood to cause, becuase it does not seem to= be in the drafts. Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: Thursday, January 07, 2010 5:25 PM > To: Ben Campbell; Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > As a participant... >=20 > >> I don't understand this argument. If intermediate proxies need to=20 > >> know, they'll need to know whether we use a REGISTER or a=20 > PUBLISH method. > >> It'll be a Proxy-Require no matter what method name. > >> > > > > I think that's the point Adam is was originally tyring to make--the=20 > > issue of intermediaries (possibly) needing to know the difference=20 > > between normal registers and bulk-registers is made no worse by the=20 > > use of PUBLISH than it would be with REGISTER. >=20 > So, as a reality check ... deployed systems today are using=20 > implicit registration with no indication that this is=20 > happening in the signaling, but the fact that this isn't=20 > visible to intermediaries today wasn't listed in Hadriel's=20 > problem statement draft. >=20 > Is this an oversight? Is anyone encountering problems with=20 > intermediaries in deployed systems using implicit registration today? >=20 > Thanks, >=20 > Spencer >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From adam@nostrum.com Thu Jan 7 10:50:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF2E28C0F1 for ; Thu, 7 Jan 2010 10:50:04 -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, 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 o+0o9ZcuAprF for ; Thu, 7 Jan 2010 10:49:59 -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 B55B83A690F for ; Thu, 7 Jan 2010 10:49:58 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07Inptn022623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 12:49:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B462CCF.70505@nostrum.com> Date: Thu, 07 Jan 2010 12:49:51 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us> <4B460AFA.9010008@nostrum.com> <4B4618A4.8010909@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020604020808060201030006" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:50:04 -0000 This is a multi-part message in MIME format. --------------020604020808060201030006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/7/10 12:41, Jan 7, Hadriel Kaplan wrote: > > ------------------------------------------------------------------------ > > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* Thursday, January 07, 2010 12:24 PM > *To:* Hadriel Kaplan > *Cc:* Richard Shockey; martini@ietf.org > *Subject:* Re: [martini] draft-roach-martini-up-00 > > On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: > > > I don't understand this argument. If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method. It'll be a Proxy-Require no matter what method name. > > > > The key difference is: > > * With REGISTER, intermediaries unaware of this extension will > think they know what the transaction means, and they will be wrong. > > No they won't. Draft shaken and stirred both ask for a new > option-tag. Right now they only mention putting them in the Require, > but if the WG decides it's necessary in Proxy-Require too that's not > exactly a big leap. > Honestly, a Proxy-Require would solve this problem from my perspective. And, now that I think about it more, it's not as bad a decision as it usually would be, since REGISTER isn't going end-to-end. One can reasonably expect this to work (unlike, say, 'Proxy-Require' in an INVITE). > * With PUBLISH, intermediaries unaware of this extension will > either correctly know that the transaction is updating state in > the network (if they understand PUBLISH), or they will simply > treat it as an unknown transaction type. In both cases, the > behavior will be correct. > > If I'm a "proxy" today with specific policies tied around > Registrations, I don't necessarily need to understand anything special > about PUBLISH today. So just using the PUBLISH method does not > automagically work. We'll need a proxy-require. > I'm not claiming it will automagically work with PUBLISH -- only that proxies will merely not take action (versus taking a potentially incorrect action) when such PUBLISH messages traverse them. /a --------------020604020808060201030006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/7/10 12:41, Jan 7, Hadriel Kaplan wrote:

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, January 07, 2010 12:24 PM
To: Hadriel Kaplan
Cc: Richard Shockey; martini@ietf.org
Subject: Re: [martini] draft-roach-martini-up-00

 

On 1/7/10 11:02, Jan 7, Hadriel Kaplan wrote: 

 
I don't understand this argument.  If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method.  It'll be a Proxy-Require no matter what method name.
 


The key difference is:

  • With REGISTER, intermediaries unaware of this extension will think they know what the transaction means, and they will be wrong.

No they won’t.  Draft shaken and stirred both ask for a new option-tag.  Right now they only mention putting them in the Require, but if the WG decides it’s necessary in Proxy-Require too that’s not exactly a big leap.


Honestly, a Proxy-Require would solve this problem from my perspective. And, now that I think about it more, it's not as bad a decision as it usually would be, since REGISTER isn't going end-to-end. One can reasonably expect this to work (unlike, say, 'Proxy-Require' in an INVITE).

  • With PUBLISH, intermediaries unaware of this extension will either correctly know that the transaction is updating state in the network (if they understand PUBLISH), or they will simply treat it as an unknown transaction type. In both cases, the behavior will be correct.

If I’m a “proxy” today with specific policies tied around Registrations, I don’t necessarily need to understand anything special about PUBLISH today.  So just using the PUBLISH method does not automagically work.  We’ll need a proxy-require.


I'm not claiming it will automagically work with PUBLISH -- only that proxies will merely not take action (versus taking a potentially incorrect action) when such PUBLISH messages traverse them.

/a

--------------020604020808060201030006-- From HKaplan@acmepacket.com Thu Jan 7 10:56:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F6D3A6918 for ; Thu, 7 Jan 2010 10:56:09 -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 35FyA7y3tDj2 for ; Thu, 7 Jan 2010 10:56:08 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 651EF3A690F for ; Thu, 7 Jan 2010 10:56:08 -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, 7 Jan 2010 13:56:05 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 13:56:06 -0500 From: Hadriel Kaplan To: Adam Roach , Spencer Dawkins Date: Thu, 7 Jan 2010 13:56:04 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvqbokmgWEIVmRuONn1P1OE/4wwACmv8A Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> In-Reply-To: <4B46196F.4020006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 18:56:09 -0000 I don't understand why you think using a REGISTER transaction makes it any = more or less architecture-specific than a PUBLISH one. =20 No matter what, we're talking about providing reachability information for = a group of AoR's, and the routing rules associated with that provided infor= mation. We already have a means of providing reachability information (Pat= h), subsequent request routes (Service-Route), and NAT traversal (outbound)= through a REGISTER transaction, just not for multiple AoR's. We can eithe= r update REGISTER to handle that latter issue, or modify PUBLISH to handle = the former issues. The advantages of using a REGISTER are fairly obvious I= would think: 1) People already use them for this purpose today. 2) We *are* actually registering something. 3) My guess is it's less code changes. I know that's not an objective con= dition, but I bet it's true. Just imagine the features people have for con= trolling REGISTER storms, using them as keepalives, tying their state to po= licies, counting them and providing their stats, etc. Heck, I bet it's eve= n easier for test equipment, since I know some of them have specific mechan= isms for REGISTER generation that wouldn't need to change to test this thin= g. -hadriel > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, January 07, 2010 12:27 PM > To: Spencer Dawkins > Cc: Ben Campbell; Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/7/10 11:25, Jan 7, Spencer Dawkins wrote: > > So, as a reality check ... deployed systems today are using implicit > > registration with no indication that this is happening in the > > signaling, but the fact that this isn't visible to intermediaries > > today wasn't listed in Hadriel's problem statement draft. > > > > Is this an oversight? Is anyone encountering problems with > > intermediaries in deployed systems using implicit registration today? >=20 > The fact that it works in a specific architecture says nothing about how > it interacts with other architectures. The proposed changes to REGISTER > are simply not backwards compatible with the protocol as it has already > been defined. A change in semantics without an indicator that will alert > all interested parties of the change in semantics is a recipe for > disaster. And intermediaries are a party to REGISTER transactions, for > better or for worse. >=20 > /a From HKaplan@acmepacket.com Thu Jan 7 11:04:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D4228C171 for ; Thu, 7 Jan 2010 11:04:59 -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 4khLjrLDqaVV for ; Thu, 7 Jan 2010 11:04:58 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3FB843A6859 for ; Thu, 7 Jan 2010 11:04:58 -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, 7 Jan 2010 14:04:55 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 14:04:56 -0500 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , Spencer Dawkins , Ben Campbell Date: Thu, 7 Jan 2010 14:04:55 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvm3IMW4YDuYsQRSiWHpHVxQuxQACzaBwAABr69A= Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 19:04:59 -0000 Actually, my mixing-draft issues were based on both IMS and non-IMS real-wo= rld deployment experiences. I know it's a myopic view since it's just my l= ist (it is only an individual draft after all - no one else posted one thou= gh). I don't know of any interoperability issues forum for IMS deployments= . I only know what I see from TAC tickets, enhancement requests, manipulat= ion rules to fix it, etc. =20 -hadriel > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Thursday, January 07, 2010 1:47 PM > To: Spencer Dawkins; Ben Campbell; Hadriel Kaplan > Cc: martini@ietf.org > Subject: RE: [martini] draft-roach-martini-up-00 >=20 > That will also be one of my questions on the call. >=20 > IMS has been using implicit registration since 2002. No one has identifie= d > any interoperability issues in the fora I attend with this. >=20 > So I would like some specifics as to what interoperability issues the use > of implicit registration is understood to cause, becuase it does not seem > to be in the drafts. >=20 > Keith >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > > Sent: Thursday, January 07, 2010 5:25 PM > > To: Ben Campbell; Hadriel Kaplan > > Cc: martini@ietf.org > > Subject: Re: [martini] draft-roach-martini-up-00 > > > > As a participant... > > > > >> I don't understand this argument. If intermediate proxies need to > > >> know, they'll need to know whether we use a REGISTER or a > > PUBLISH method. > > >> It'll be a Proxy-Require no matter what method name. > > >> > > > > > > I think that's the point Adam is was originally tyring to make--the > > > issue of intermediaries (possibly) needing to know the difference > > > between normal registers and bulk-registers is made no worse by the > > > use of PUBLISH than it would be with REGISTER. > > > > So, as a reality check ... deployed systems today are using > > implicit registration with no indication that this is > > happening in the signaling, but the fact that this isn't > > visible to intermediaries today wasn't listed in Hadriel's > > problem statement draft. > > > > Is this an oversight? Is anyone encountering problems with > > intermediaries in deployed systems using implicit registration today? > > > > Thanks, > > > > Spencer > > > > > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > From HKaplan@acmepacket.com Thu Jan 7 11:09:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9952A28C1A7 for ; Thu, 7 Jan 2010 11:09: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=[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 wVXKmRks78DJ for ; Thu, 7 Jan 2010 11:09:13 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3554F3A6859 for ; Thu, 7 Jan 2010 11:09:11 -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, 7 Jan 2010 14:09:07 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 7 Jan 2010 14:09:08 -0500 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "martini@ietf.org" Date: Thu, 7 Jan 2010 14:09:07 -0500 Thread-Topic: [martini] Comments on draft-kaplan-martini-mixing-problems-00 Thread-Index: AcqO35nAG4kI9e3ORH2eKoHrt/5ACAA7QDlg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 19:09:14 -0000 BTW, in my defense, this wasn't a Requirements document/draft. A call went out asking for drafts on "Discussions of currently deployed mec= hanisms for multiple AOR registration, and their pros and cons." And that'= s basically what I tried to write up, though more as a problems list. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: Wednesday, January 06, 2010 9:51 AM > To: martini@ietf.org > Subject: [martini] Comments on draft-kaplan-martini-mixing-problems-00 >=20 >=20 > I do not think this document adequately addresses a set of requirements, > and I suspect a set of clearly stated requirements do need to be put in > place before further significant further work is performed. From spencer@wonderhamster.org Thu Jan 7 14:11:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC143A689F for ; Thu, 7 Jan 2010 14:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=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 wHy9uFdNR2XH for ; Thu, 7 Jan 2010 14:11:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 3EE1A3A687D for ; Thu, 7 Jan 2010 14:11:08 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M6BvO-1NqhFk1EqI-00yIkc; Thu, 07 Jan 2010 17:11:06 -0500 Message-ID: <8B3D218A59E9419D9232D5EBAD159F87@china.huawei.com> From: "Spencer Dawkins" To: "Hadriel Kaplan" , "DRAGE, Keith \(Keith\)" , References: Date: Thu, 7 Jan 2010 16:10:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX189p4WrXY6q3mo5t8/Q+IiN+Pz4t06JOPY2uBs 1LklH7bqyVT04WK+PH0dxLrtTIQkwE/mr1OGSruFVgkZu/YRyj 9srb50kQKG97vdIjUM5fGw/AmqKDCfYy6IvwulzZ6Q= Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:11:10 -0000 Hadriel, Thanks for putting this document forward. Spencer ----- Original Message ----- From: "Hadriel Kaplan" To: "DRAGE, Keith (Keith)" ; Sent: Thursday, January 07, 2010 1:09 PM Subject: Re: [martini] Comments on draft-kaplan-martini-mixing-problems-00 > > BTW, in my defense, this wasn't a Requirements document/draft. > A call went out asking for drafts on "Discussions of currently deployed > mechanisms for multiple AOR registration, and their pros and cons." And > that's basically what I tried to write up, though more as a problems list. > > -hadriel > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf >> Of DRAGE, Keith (Keith) >> Sent: Wednesday, January 06, 2010 9:51 AM >> To: martini@ietf.org >> Subject: [martini] Comments on draft-kaplan-martini-mixing-problems-00 >> >> >> I do not think this document adequately addresses a set of requirements, >> and I suspect a set of clearly stated requirements do need to be put in >> place before further significant further work is performed. > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Thu Jan 7 14:23:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01A428C112 for ; Thu, 7 Jan 2010 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1xBsSuNp1GKU for ; Thu, 7 Jan 2010 14:23:11 -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 5DF953A684A for ; Thu, 7 Jan 2010 14:23:10 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07MN5b3038486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 16:23:06 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B465EC9.5050709@nostrum.com> Date: Thu, 07 Jan 2010 16:23:05 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:23:12 -0000 On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > I don't understand why you think using a REGISTER transaction makes it any more or less architecture-specific than a PUBLISH one. > That's not what I'm saying. There's been a lot of back-and-forth on this topic that amounts to the same exchange over and over (not just with you; with several parties). I'm going to replay the dialog in simplified form, because I think something is getting lost with the flood of email messages: A: "Changing REGISTER in this way can break intermediaries." B: "But in the architecture MARTINI is considering, it breaks nothing." A: "The fact that it works in one place does not mean it works everywhere." Changing the established meaning of REGISTER can cause problems unless all parties to the transaction understand the changes. The fact that no such problem arises in one specific architecture seems to be held out as proof that it must work everywhere. Which is the logical equivalent to: "this particular swan is white, therefore all swans must be white." (cf http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inference) What I'm proposing with PUBLISH isn't a change to established semantics. In fact, it aligns precisely with established semantics: as I said on the phone, the basic concept of using PUBLISH to update a Location Service database could be a BCP, since it requires no new protocol mechanism. Nothing breaks, since the meaning of everything remains the same. Everything else I've proposed so far is properly negotiated SIP protocol extensions using established extension mechanisms. You could do the same thing with REGISTER, if you really wanted to, by using both Require and Proxy-Require. /a From christer.holmberg@ericsson.com Thu Jan 7 14:39:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CEC28C0D0 for ; Thu, 7 Jan 2010 14:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.544 X-Spam-Level: X-Spam-Status: No, score=-5.544 tagged_above=-999 required=5 tests=[AWL=0.705, 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 K3srGjlj2RW7 for ; Thu, 7 Jan 2010 14:39:22 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 88F443A684A for ; Thu, 7 Jan 2010 14:39:22 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-98-4b4662978d3d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id C3.01.04178.792664B4; Thu, 7 Jan 2010 23:39:19 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 7 Jan 2010 23:39:19 +0100 From: Christer Holmberg To: 'Adam Roach' , Hadriel Kaplan Date: Thu, 7 Jan 2010 23:39:17 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP6A31sN3kHPgsQP66c4oQByYRCgAAOYog Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> In-Reply-To: <4B465EC9.5050709@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:39:23 -0000 Hi, I think one of the reason we go over the same thing over and over is becaus= e we don't have a common view on the "user" concept. Adam talks about multiple users, and that using a single REGISTER for those= breaks things. Keith (and maybe others) seems to be arguing that we are st= ill talking about a SINGLE SIP user. What happens inside the PBX is irrelev= ant. The PBX users have a relation with the PBX - the PBX has a relation wi= th the SIP network. So, from Keith's perspective things would not be broken, and intermediates = in the SIP network do not (at least not by default) need to be aware of ind= ividual users behind the PBX. But, I may have missunderstood, and in that case I appologize :) Regards, Christer =20 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 8. tammikuuta 2010 0:23 To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > I don't understand why you think using a REGISTER transaction makes it an= y more or less architecture-specific than a PUBLISH one. > =20 That's not what I'm saying. There's been a lot of back-and-forth on this to= pic that amounts to the same exchange over and over (not just with you; wit= h several parties). I'm going to replay the dialog in simplified form, beca= use I think something is getting lost with the flood of email messages: A: "Changing REGISTER in this way can break intermediaries." B: "But in the architecture MARTINI is considering, it breaks nothing." A: "The fact that it works in one place does not mean it works everywhere." Changing the established meaning of REGISTER can cause problems unless all = parties to the transaction understand the changes. The fact that no such pr= oblem arises in one specific architecture seems to be held out as proof tha= t it must work everywhere. Which is the logical equivalent to:=20 "this particular swan is white, therefore all swans must be white." (cf http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inference= ) What I'm proposing with PUBLISH isn't a change to established semantics.=20 In fact, it aligns precisely with established semantics: as I said on the p= hone, the basic concept of using PUBLISH to update a Location Service datab= ase could be a BCP, since it requires no new protocol mechanism. Nothing br= eaks, since the meaning of everything remains the same. Everything else I've proposed so far is properly negotiated SIP protocol ex= tensions using established extension mechanisms. You could do the same thin= g with REGISTER, if you really wanted to, by using both Require and Proxy-R= equire. /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Thu Jan 7 14:48:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CA13A6890 for ; Thu, 7 Jan 2010 14:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZevHsgxqUCiC for ; Thu, 7 Jan 2010 14:48: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 7D8213A6849 for ; Thu, 7 Jan 2010 14:48:43 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o07MmaPG040434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 16:48:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4664C4.2060403@nostrum.com> Date: Thu, 07 Jan 2010 16:48:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Christer Holmberg References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 22:48:45 -0000 You're spot on in describing the differences in perspectives. I think it comes down to whether you see an application for SIP outside of IMS architectures. In IMS-derived architectures, you can make the assumptions Keith has. In the general case, I don't think they hold. /a On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > Hi, > > I think one of the reason we go over the same thing over and over is because we don't have a common view on the "user" concept. > > Adam talks about multiple users, and that using a single REGISTER for those breaks things. Keith (and maybe others) seems to be arguing that we are still talking about a SINGLE SIP user. What happens inside the PBX is irrelevant. The PBX users have a relation with the PBX - the PBX has a relation with the SIP network. > > So, from Keith's perspective things would not be broken, and intermediates in the SIP network do not (at least not by default) need to be aware of individual users behind the PBX. > > But, I may have missunderstood, and in that case I appologize :) > > Regards, > > Christer > > > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 8. tammikuuta 2010 0:23 > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > >> I don't understand why you think using a REGISTER transaction makes it any more or less architecture-specific than a PUBLISH one. >> >> > That's not what I'm saying. There's been a lot of back-and-forth on this topic that amounts to the same exchange over and over (not just with you; with several parties). I'm going to replay the dialog in simplified form, because I think something is getting lost with the flood of email > messages: > > A: "Changing REGISTER in this way can break intermediaries." > B: "But in the architecture MARTINI is considering, it breaks nothing." > A: "The fact that it works in one place does not mean it works everywhere." > > Changing the established meaning of REGISTER can cause problems unless all parties to the transaction understand the changes. The fact that no such problem arises in one specific architecture seems to be held out as proof that it must work everywhere. Which is the logical equivalent to: > "this particular swan is white, therefore all swans must be white." (cf > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inference) > > What I'm proposing with PUBLISH isn't a change to established semantics. > In fact, it aligns precisely with established semantics: as I said on the phone, the basic concept of using PUBLISH to update a Location Service database could be a BCP, since it requires no new protocol mechanism. Nothing breaks, since the meaning of everything remains the same. > > Everything else I've proposed so far is properly negotiated SIP protocol extensions using established extension mechanisms. You could do the same thing with REGISTER, if you really wanted to, by using both Require and Proxy-Require. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From christer.holmberg@ericsson.com Thu Jan 7 15:01:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A7B3A6851 for ; Thu, 7 Jan 2010 15:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.470, 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 E9Dykhib-3UC for ; Thu, 7 Jan 2010 15:01:30 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D422A3A67E3 for ; Thu, 7 Jan 2010 15:01:29 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-79-4b4667c77806 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id EF.F1.04178.7C7664B4; Fri, 8 Jan 2010 00:01:27 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 8 Jan 2010 00:01:26 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Fri, 8 Jan 2010 00:01:24 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP645MqYBeO+01TdGZMRa0BEh19wAAVV2g Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> In-Reply-To: <4B4664C4.2060403@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:01:31 -0000 Hi,=20 >You're spot on in describing the differences in perspectives. I think it c= omes down to whether you see an application for SIP outside of IMS architec= tures. > >In IMS-derived architectures, you can make the assumptions Keith has. In t= he general case, I don't think they hold. Well, that is what we need to decide, before discussing SIP methods and pro= tocol details :) Regards, Christer On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > Hi, > > I think one of the reason we go over the same thing over and over is beca= use we don't have a common view on the "user" concept. > > Adam talks about multiple users, and that using a single REGISTER for tho= se breaks things. Keith (and maybe others) seems to be arguing that we are = still talking about a SINGLE SIP user. What happens inside the PBX is irrel= evant. The PBX users have a relation with the PBX - the PBX has a relation = with the SIP network. > > So, from Keith's perspective things would not be broken, and intermediate= s in the SIP network do not (at least not by default) need to be aware of i= ndividual users behind the PBX. > > But, I may have missunderstood, and in that case I appologize :) > > Regards, > > Christer > > > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > Behalf Of Adam Roach > Sent: 8. tammikuuta 2010 0:23 > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > =20 >> I don't understand why you think using a REGISTER transaction makes it a= ny more or less architecture-specific than a PUBLISH one. >> >> =20 > That's not what I'm saying. There's been a lot of back-and-forth on=20 > this topic that amounts to the same exchange over and over (not just=20 > with you; with several parties). I'm going to replay the dialog in=20 > simplified form, because I think something is getting lost with the=20 > flood of email > messages: > > A: "Changing REGISTER in this way can break intermediaries." > B: "But in the architecture MARTINI is considering, it breaks nothing." > A: "The fact that it works in one place does not mean it works everywhere= ." > > Changing the established meaning of REGISTER can cause problems unless al= l parties to the transaction understand the changes. The fact that no such = problem arises in one specific architecture seems to be held out as proof t= hat it must work everywhere. Which is the logical equivalent to: > "this particular swan is white, therefore all swans must be white."=20 > (cf > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_infe > rence) > > What I'm proposing with PUBLISH isn't a change to established semantics. > In fact, it aligns precisely with established semantics: as I said on the= phone, the basic concept of using PUBLISH to update a Location Service dat= abase could be a BCP, since it requires no new protocol mechanism. Nothing = breaks, since the meaning of everything remains the same. > > Everything else I've proposed so far is properly negotiated SIP protocol = extensions using established extension mechanisms. You could do the same th= ing with REGISTER, if you really wanted to, by using both Require and Proxy= -Require. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > =20 From bernard_aboba@hotmail.com Thu Jan 7 15:56:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7083A6880 for ; Thu, 7 Jan 2010 15:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.805 X-Spam-Level: X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[AWL=-0.807, 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 eplF-FeyMhI4 for ; Thu, 7 Jan 2010 15:56:02 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id 55C6E3A6767 for ; Thu, 7 Jan 2010 15:56:02 -0800 (PST) Received: from BLU137-W9 ([65.55.111.72]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 15:56:00 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a5fa331b-ce43-4256-8f08-fbdb1d860ead_" X-Originating-IP: [131.107.0.77] From: Bernard Aboba To: Date: Thu, 7 Jan 2010 15:56:00 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jan 2010 23:56:00.0479 (UTC) FILETIME=[F68E3EF0:01CA8FF4] Subject: [martini] Minutes... X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 23:56:03 -0000 --_a5fa331b-ce43-4256-8f08-fbdb1d860ead_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took notes during the MARTINI Virtual Interim today=2C please send t= hem to Spencer and myself.=20 = --_a5fa331b-ce43-4256-8f08-fbdb1d860ead_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took notes during the MARTINI Virtual Interim today=2C please send t= hem to Spencer and myself.
<= tbody>

= --_a5fa331b-ce43-4256-8f08-fbdb1d860ead_-- From bernard_aboba@hotmail.com Thu Jan 7 16:12:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37F43A6925 for ; Thu, 7 Jan 2010 16:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 WJydfmZfK5Wd for ; Thu, 7 Jan 2010 16:12:03 -0800 (PST) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 8BE9F3A68B4 for ; Thu, 7 Jan 2010 16:12:01 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 16:12:00 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 7 Jan 2010 16:11:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0365_01CA8FB4.2224E910" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqP9zAOFuWnP2rgQ6SZQD4S1EOudA== Content-Language: en-us X-OriginalArrivalTime: 08 Jan 2010 00:12:00.0139 (UTC) FILETIME=[328EBDB0:01CA8FF7] Subject: [martini] Scheduling MARTINI Virtual Interim II X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:12:06 -0000 ------=_NextPart_000_0365_01CA8FB4.2224E910 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So that we can make rapid progress, we will be scheduling 2nd and 3rd MARTINI Virtual Interim meetings. Please help us schedule these meetings by participating in the following Doodle Polls: Poll for 2nd Virtual Interim (Week of January 25, 2010): http://www.doodle.com/3r4wi9kbrnrx4ypk Poll for 3rd Virtual Interim (Week of February 8, 2010): http://www.doodle.com/7q5s2sm9wwb8md2n ------=_NextPart_000_0365_01CA8FB4.2224E910 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So that we can make rapid progress, we will be = scheduling 2nd and 3rd MARTINI Virtual Interim meetings.

 

Please help us schedule these meetings by = participating in the following Doodle Polls:

 

Poll for 2nd Virtual Interim (Week of = January 25, 2010): http://www.doodle.com/3r4= wi9kbrnrx4ypk

Poll for 3rd Virtual Interim (Week of = February 8, 2010): http://www.doodle.com/7q5= s2sm9wwb8md2n

 

 

------=_NextPart_000_0365_01CA8FB4.2224E910-- From bernard_aboba@hotmail.com Thu Jan 7 16:32:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FCAC3A681B for ; Thu, 7 Jan 2010 16:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_05=-1.11, 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 4v14BuSENXoG for ; Thu, 7 Jan 2010 16:32:11 -0800 (PST) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id ADFA83A672F for ; Thu, 7 Jan 2010 16:32:11 -0800 (PST) Received: from BLU137-W2 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 16:32:10 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_cb32717b-49bf-48c8-b2c4-e842beb0eea3_" X-Originating-IP: [131.107.0.83] From: Bernard Aboba To: Date: Thu, 7 Jan 2010 16:32:10 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2010 00:32:10.0479 (UTC) FILETIME=[03F9F7F0:01CA8FFA] Subject: [martini] Implicit Registration Interoperability Issues X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:32:12 -0000 --_cb32717b-49bf-48c8-b2c4-e842beb0eea3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keith Drage said: =20 "IMS has been using implicit registration since 2002. No one has identified= any interoperability issues in the fora I attend with this. So I would like some specifics as to what interoperability issues the use o= f implicit registration is understood to cause=2C because it does not seem = to be in the drafts." =20 The draft attempts to describe interop issues encountered with the 3GPP=2C = ETSI=2C Cablelabs and "adhoc" models.=20 =20 During the meeting=2C you described some problems in the draft's characteri= zation of IMS implicit registration. It might be helpful if you could des= cribe in more detail on the list what a more correct characterization would= be.=20 =20 = --_cb32717b-49bf-48c8-b2c4-e842beb0eea3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Keith Drage said:
 =3B
"IMS has been using implicit registration since 2002. No one has identified= any interoperability issues in the fora I attend with this.

So I wo= uld like some specifics as to what interoperability issues the use of impli= cit registration is understood to cause=2C because it does not seem to be i= n the drafts."
 =3B
The draft attempts to describe interop issues encountered with the 3GPP=2C = ETSI=2C Cablelabs and "adhoc" models.
 =3B
During the meeting=2C you described some problems in the draft's characteri= zation of IMS implicit registration. =3B =3B It might be helpful if= you could describe in more detail on the list what a more correct characte= rization would be.

 =3B
= --_cb32717b-49bf-48c8-b2c4-e842beb0eea3_-- From pkyzivat@cisco.com Thu Jan 7 16:40:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6213E3A6927 for ; Thu, 7 Jan 2010 16:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.226 X-Spam-Level: X-Spam-Status: No, score=-10.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JVOFLfHot3P for ; Thu, 7 Jan 2010 16:40:38 -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 87E6C3A6914 for ; Thu, 7 Jan 2010 16:40:38 -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: ApoEAL4NRkurRN+J/2dsb2JhbADAVJQshC8E X-IronPort-AV: E=Sophos;i="4.49,238,1262563200"; d="scan'208";a="130046974" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 08 Jan 2010 00:40:37 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o080eb5b013394; Fri, 8 Jan 2010 00:40:37 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 18:40:37 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jan 2010 18:40:36 -0600 Message-ID: <4B467F03.7080502@cisco.com> Date: Thu, 07 Jan 2010 19:40:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 00:40:36.0549 (UTC) FILETIME=[319E1F50:01CA8FFB] Cc: "martini@ietf.org" Subject: Re: [martini] Provisioning Load X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 00:40:39 -0000 DRAGE, Keith (Keith) wrote: > At least for IMS, it means that there is one user record in the SPP database, rather than one for each URI. Given that all those records, if separate, would essentially need the same information, that is the saving to the operator in terms of provisioning time. I don't know anything about this DB. When a user has multiple AORs, are they all in this single record? With a typical user, I suppose the number of AORs there is typically in range of 1-3 or so, right? Is that same DB used when the number of AORs becomes 100,200,300... ??? Thanks, Paul > Of course you could always argue that all these duplicate records could be created by some sort of intelligent front end, but ... > > Keith > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Thursday, January 07, 2010 5:09 PM >> To: martini@ietf.org >> Subject: [martini] Provisioning Load >> >> There's been a lot of discussion that the provisioning load >> for an SSP to simply provision routes to each IP-PBX is unacceptable. >> >> But if I understand the shaken draft, the SPP will still have >> to provision the following information for _each_ pbx: >> >> -- The magic one-true AoR, both at the SPP and the PBX. ("One >> AoR to bind them...) >> -- The list of implicit AoRs. (either as a list or some sort >> of range, transformation, wildcard, etc) >> >> So how does adding "Route to PBX" make things that much >> worse? It seems like a fairly small incremental difference. >> >> Is it just that the pbx may have an dynamic address? >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From drage@alcatel-lucent.com Thu Jan 7 17:01:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E173A6826 for ; Thu, 7 Jan 2010 17:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.909, 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 P90bvwbtzTRk for ; Thu, 7 Jan 2010 17:01:01 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id BC7633A67E3 for ; Thu, 7 Jan 2010 17:01:00 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0810s7L026661 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Jan 2010 02:00:54 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 8 Jan 2010 02:00:54 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Fri, 8 Jan 2010 02:00:52 +0100 Thread-Topic: [martini] Provisioning Load Thread-Index: AcqP+zceksmNZJAiQLyTEqKKhIWEpwAAg7PA Message-ID: References: <29F9CCB4-752B-4B5C-AAEB-E3A0EF7C8E95@nostrum.com> <4B467F03.7080502@cisco.com> In-Reply-To: <4B467F03.7080502@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] Provisioning Load X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 01:01:01 -0000 The database is the HSS. It is the same database for normal user access to IMS and for the subscript= ion based business trunking. It is essentially one database record for each private user identity, of wh= ich an attached PBX would generally have one. For a business trunking user, I would expect that one record to have one or= two default public user identities (SIP and tel) and one or two wildcarded= public user identities (i.e. an expression that covers at set of ranges fo= r both SIP and tel). None of the URIs to which this expression resolves wou= ld be individually stored in the database.=20 Obviously there may be other special URIs. Now 3GPP does not define the implementation of the database itself, only th= e protocol that is used to access the database, some of this represents wha= t appears in that protocol rather than what a vendor may have actually impl= emented to obtain rapid resolution of database queries. regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, January 08, 2010 12:41 AM > To: DRAGE, Keith (Keith) > Cc: Ben Campbell; martini@ietf.org > Subject: Re: [martini] Provisioning Load >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > At least for IMS, it means that there is one user record in=20 > the SPP database, rather than one for each URI. Given that=20 > all those records, if separate, would essentially need the=20 > same information, that is the saving to the operator in terms=20 > of provisioning time. >=20 > I don't know anything about this DB. When a user has multiple=20 > AORs, are they all in this single record? >=20 > With a typical user, I suppose the number of AORs there is=20 > typically in range of 1-3 or so, right? >=20 > Is that same DB used when the number of AORs becomes=20 > 100,200,300... ??? >=20 > Thanks, > Paul >=20 > > Of course you could always argue that all these duplicate=20 > records could be created by some sort of intelligent front=20 > end, but ... > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Ben Campbell > >> Sent: Thursday, January 07, 2010 5:09 PM > >> To: martini@ietf.org > >> Subject: [martini] Provisioning Load > >> > >> There's been a lot of discussion that the provisioning load for an=20 > >> SSP to simply provision routes to each IP-PBX is unacceptable. > >> > >> But if I understand the shaken draft, the SPP will still have to=20 > >> provision the following information for _each_ pbx: > >> > >> -- The magic one-true AoR, both at the SPP and the PBX.=20 > ("One AoR to=20 > >> bind them...) > >> -- The list of implicit AoRs. (either as a list or some sort of=20 > >> range, transformation, wildcard, etc) > >> > >> So how does adding "Route to PBX" make things that much worse? It=20 > >> seems like a fairly small incremental difference. > >> > >> Is it just that the pbx may have an dynamic address?=20 > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > = From john.elwell@siemens-enterprise.com Fri Jan 8 02:28:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA133A6945 for ; Fri, 8 Jan 2010 02:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MExkLk2SQfgD for ; Fri, 8 Jan 2010 02:28:53 -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 44E2A3A68EF for ; Fri, 8 Jan 2010 02:28:52 -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-474368; Fri, 8 Jan 2010 11:28:48 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 137591EB829C; Fri, 8 Jan 2010 11:28:48 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Jan 2010 11:28:48 +0100 From: "Elwell, John" To: Adam Roach , Christer Holmberg Date: Fri, 8 Jan 2010 11:28:47 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP65KxO6rNEx8qRwS919b8/WYnvQAYQ3kQ Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> In-Reply-To: <4B4664C4.2060403@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 10:28:55 -0000 I think Christer's summary is good. The architecture that Keith and others = are talking about is applicable outside IMS too - that is what the SIP Foru= m is trying to achieve with SIPconnect - a means for a PBX to register. Thi= s was probably a lot clearer with the earlier domain registration draft ("s= tirred"), but it is still the same principle with the current implicit regi= stration draft ("shaken"). John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 07 January 2010 22:49 > To: Christer Holmberg > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > You're spot on in describing the differences in perspectives.=20 > I think it=20 > comes down to whether you see an application for SIP outside of IMS=20 > architectures. >=20 > In IMS-derived architectures, you can make the assumptions=20 > Keith has. In=20 > the general case, I don't think they hold. >=20 > /a >=20 > On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > > Hi, > > > > I think one of the reason we go over the same thing over=20 > and over is because we don't have a common view on the "user" concept. > > > > Adam talks about multiple users, and that using a single=20 > REGISTER for those breaks things. Keith (and maybe others)=20 > seems to be arguing that we are still talking about a SINGLE=20 > SIP user. What happens inside the PBX is irrelevant. The PBX=20 > users have a relation with the PBX - the PBX has a relation=20 > with the SIP network. > > > > So, from Keith's perspective things would not be broken,=20 > and intermediates in the SIP network do not (at least not by=20 > default) need to be aware of individual users behind the PBX. > > > > But, I may have missunderstood, and in that case I appologize :) > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 8. tammikuuta 2010 0:23 > > To: Hadriel Kaplan > > Cc: martini@ietf.org > > Subject: Re: [martini] draft-roach-martini-up-00 > > > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > > =20 > >> I don't understand why you think using a REGISTER=20 > transaction makes it any more or less architecture-specific=20 > than a PUBLISH one. > >> > >> =20 > > That's not what I'm saying. There's been a lot of=20 > back-and-forth on this topic that amounts to the same=20 > exchange over and over (not just with you; with several=20 > parties). I'm going to replay the dialog in simplified form,=20 > because I think something is getting lost with the flood of email > > messages: > > > > A: "Changing REGISTER in this way can break intermediaries." > > B: "But in the architecture MARTINI is considering, it=20 > breaks nothing." > > A: "The fact that it works in one place does not mean it=20 > works everywhere." > > > > Changing the established meaning of REGISTER can cause=20 > problems unless all parties to the transaction understand the=20 > changes. The fact that no such problem arises in one specific=20 > architecture seems to be held out as proof that it must work=20 > everywhere. Which is the logical equivalent to: > > "this particular swan is white, therefore all swans must be=20 > white." (cf > >=20 > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori > cal_inference) > > > > What I'm proposing with PUBLISH isn't a change to=20 > established semantics. > > In fact, it aligns precisely with established semantics: as=20 > I said on the phone, the basic concept of using PUBLISH to=20 > update a Location Service database could be a BCP, since it=20 > requires no new protocol mechanism. Nothing breaks, since the=20 > meaning of everything remains the same. > > > > Everything else I've proposed so far is properly negotiated=20 > SIP protocol extensions using established extension=20 > mechanisms. You could do the same thing with REGISTER, if you=20 > really wanted to, by using both Require and Proxy-Require. > > > > /a > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > =20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From HKaplan@acmepacket.com Fri Jan 8 06:18:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511313A6958 for ; Fri, 8 Jan 2010 06:18:22 -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 XshJ-SfeHx4M for ; Fri, 8 Jan 2010 06:18:21 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 111943A6884 for ; Fri, 8 Jan 2010 06:18:20 -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; Fri, 8 Jan 2010 09:18:16 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Jan 2010 09:18:16 -0500 From: Hadriel Kaplan To: Adam Roach Date: Fri, 8 Jan 2010 09:18:15 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP6AantfAH6Jz3Qoa2rNjzoAL1gwAhO8+Q Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> In-Reply-To: <4B465EC9.5050709@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 14:18:22 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, January 07, 2010 5:23 PM >=20 > A: "Changing REGISTER in this way can break intermediaries." > B: "But in the architecture MARTINI is considering, it breaks nothing." > A: "The fact that it works in one place does not mean it works > everywhere." >=20 > Changing the established meaning of REGISTER can cause problems unless > all parties to the transaction understand the changes. The fact that no > such problem arises in one specific architecture seems to be held out as > proof that it must work everywhere. Which is the logical equivalent to: > "this particular swan is white, therefore all swans must be white." (cf > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inferen= c > e) Right, and you and I are in agreement on that point. > Everything else I've proposed so far is properly negotiated SIP protocol > extensions using established extension mechanisms. You could do the same > thing with REGISTER, if you really wanted to, by using both Require and > Proxy-Require. Right, and my point was that PUBLISH would need a Require/Proxy-Require too= . -hadriel From adam@nostrum.com Fri Jan 8 06:51:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF5E3A697E for ; Fri, 8 Jan 2010 06:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDrcmi-eCBQc for ; Fri, 8 Jan 2010 06:51:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 34C4C3A697A for ; Fri, 8 Jan 2010 06:51:40 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o08EpZHs060683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 08:51:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B474677.9090803@nostrum.com> Date: Fri, 08 Jan 2010 08:51:35 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 14:51:42 -0000 On 1/8/10 8:18 AM, Hadriel Kaplan wrote: > >> Everything else I've proposed so far is properly negotiated SIP protocol >> extensions using established extension mechanisms. You could do the same >> thing with REGISTER, if you really wanted to, by using both Require and >> Proxy-Require. >> > Right, and my point was that PUBLISH would need a Require/Proxy-Require too. > I don't think it does, because we're not changing the semantics of PUBLISH. I believe that the only need for option-tags at all is for the Path and Service-Route handling, and we simply copy that behavior from RFCs 3327 and 3608. /a From alan@sipstation.com Fri Jan 8 06:52:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6279E3A6985 for ; Fri, 8 Jan 2010 06:52:34 -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 76U5uN10W2tD for ; Fri, 8 Jan 2010 06:52:33 -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 B6D8C3A68C2 for ; Fri, 8 Jan 2010 06:52:32 -0800 (PST) Received: from 24-107-197-239.dhcp.stls.mo.charter.com ([24.107.197.239] helo=Alans-PowerBook-G4-17.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NTGCR-0004LF-4e; Fri, 08 Jan 2010 14:52:28 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.239 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX186NCPsYPRm7OTOZPnoUQDmH86wdZz/Nfg= Message-ID: <4B4746A8.2030602@sipstation.com> Date: Fri, 08 Jan 2010 08:52:24 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> In-Reply-To: <4B462820.4010702@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 14:52:34 -0000 Adam, You missed my point. My point was that an intermediary "proxy" should not try to infer any semantics from a REGISTER - not that one can not imagine an architecture where this could break things. The REGISTER method is between the UA and the Registrar, and I don't recall anything in Section 16 of RFC 3261 behavior (which defines a SIP proxy) that is REGISTER specific. If this "proxy" is trying to infer semantics from a REGISTER, then it is effectively no longer a proxy (per RFC 3261) but instead is acting a Registrar. If so, then, it must understand the option tag in order to infer correct semantics from the REGISTER. In some of your other posts, you seem to be arguing that we should not and can not make any changes to a method semantics since this might break intermediaries. However, we have done this in the past - take everyone's favorite method REFER. With RFC 4488, we used a header field and option tag to indicate that there will be no NOTIFY to the REFER. This could potentially break an intermediary which sees the REFER, only understands RFC 3515 which defines REFER, and expects to see NOTIFYs. However, again, this is another case where an intermediary is trying to infer semantics from a method, and as such, it is effectively no longer a proxy and is now behaving like a UA and must understand things like option tags, etc. - Alan - Adam Roach wrote: > On 1/7/10 10:47, Jan 7, Alan Johnston wrote: > >> What kinds of sensible things could an intermediary proxy do with >> such a REGISTER? And what problems would this cause? >> >> I could only imagine a proxy which is part of either the service >> provider domain or the enterprise domain doing anything sensible with >> the REGISTER, and both of these would recognize it as as what it is. > > Yes, for the large part, the architectures people are _currently_ > looking at will be limited to these two situations. And, for those > architectures, your assertion holds. > > Here's the issue I have: SIP is designed to be an extensible, flexible > protocol that can be used for arbitrary architectures. That design is > intended to foster innovation, instead of locking down the network > architecture into a small set of blessed configurations. > > If we take actions that preclude certain architectures -- even if we > can't design those architectures right now -- then we limit SIP's > flexibility. We constrain innovation. > > Certainly we're not hubristic enough to think that we can predict all > possible useful architectures. But we can at least identify where > inherent aspects of the protocol are being modified, and avoid doing > them in an incompatible fashion. > > /a > From HKaplan@acmepacket.com Fri Jan 8 06:58:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23B03A68B2 for ; Fri, 8 Jan 2010 06:58:40 -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 V8C9NIfYR3fF for ; Fri, 8 Jan 2010 06:58:39 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BA9253A6895 for ; Fri, 8 Jan 2010 06:58:39 -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; Fri, 8 Jan 2010 09:58:37 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Jan 2010 09:58:37 -0500 From: Hadriel Kaplan To: Alan Johnston , Adam Roach Date: Fri, 8 Jan 2010 09:58:35 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqQcj5uNCS/W8NCTGGsIspRs7R4qgAAKuuw Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> In-Reply-To: <4B4746A8.2030602@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 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 14:58:40 -0000 Yeah this is why the stirred/shaken drafts only have an option-tag in Requi= re right now. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Alan Johnston > Sent: Friday, January 08, 2010 9:52 AM >=20 > My point was that an intermediary "proxy" should not try to infer any > semantics from a REGISTER - not that one can not imagine an architecture > where this could break things. The REGISTER method is between the UA > and the Registrar, and I don't recall anything in Section 16 of RFC 3261 > behavior (which defines a SIP proxy) that is REGISTER specific. >=20 > If this "proxy" is trying to infer semantics from a REGISTER, then it is > effectively no longer a proxy (per RFC 3261) but instead is acting a > Registrar. If so, then, it must understand the option tag in order to > infer correct semantics from the REGISTER. >=20 > In some of your other posts, you seem to be arguing that we should not > and can not make any changes to a method semantics since this might > break intermediaries. However, we have done this in the past - take > everyone's favorite method REFER. With RFC 4488, we used a header field > and option tag to indicate that there will be no NOTIFY to the REFER. > This could potentially break an intermediary which sees the REFER, only > understands RFC 3515 which defines REFER, and expects to see NOTIFYs. > However, again, this is another case where an intermediary is trying to > infer semantics from a method, and as such, it is effectively no longer > a proxy and is now behaving like a UA and must understand things like > option tags, etc. >=20 > - Alan - >=20 From HKaplan@acmepacket.com Fri Jan 8 07:02:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00813A683C for ; Fri, 8 Jan 2010 07:02:54 -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 WRJ8S8S8PUV2 for ; Fri, 8 Jan 2010 07:02:54 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D1DC53A6811 for ; Fri, 8 Jan 2010 07:02:53 -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; Fri, 8 Jan 2010 10:02:51 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Jan 2010 10:02:51 -0500 From: Hadriel Kaplan To: Adam Roach Date: Fri, 8 Jan 2010 10:02:50 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqQchTQniP0sSeTRQGVrhlvWxRlbgAAPoaQ Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B474677.9090803@nostrum.com> In-Reply-To: <4B474677.9090803@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 15:02:54 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Friday, January 08, 2010 9:52 AM > To: Hadriel Kaplan >=20 > On 1/8/10 8:18 AM, Hadriel Kaplan wrote: > > Right, and my point was that PUBLISH would need a Require/Proxy-Require > too. >=20 > I don't think it does, because we're not changing the semantics of PUBLIS= H. You're not changing the semantics of the PUBLISH, because it has almost no = semantics to begin with. Everything "important/unique" about it is tied to= the event package name and body. So you need a Req/P-Req to say "you must= understand this event package to process this PUBLISH". In other words, if the argument against using REGISTER without a Req/P-Req = is "but that breaks things that expected REGISTER to work differently", the= n presumably those things need to understand this specific PUBLISH usage to= o for whatever reasons they needed to understand REGISTER semantics. -hadriel From adam@nostrum.com Fri Jan 8 07:16:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3123A684D for ; Fri, 8 Jan 2010 07:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NXp+6b12VK7 for ; Fri, 8 Jan 2010 07:16: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 92FAE3A6811 for ; Fri, 8 Jan 2010 07:16:19 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o08FGFJA062680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 09:16:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B474C3F.7090601@nostrum.com> Date: Fri, 08 Jan 2010 09:16:15 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Alan Johnston References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> In-Reply-To: <4B4746A8.2030602@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 15:16:21 -0000 On 1/8/10 8:52 AM, Alan Johnston wrote: > My point was that an intermediary "proxy" should not try to infer any > semantics from a REGISTER - not that one can not imagine an > architecture where this could break things. The REGISTER method is > between the UA and the Registrar, and I don't recall anything in > Section 16 of RFC 3261 behavior (which defines a SIP proxy) that is > REGISTER specific. > > If this "proxy" is trying to infer semantics from a REGISTER, then it > is effectively no longer a proxy (per RFC 3261) but instead is acting > a Registrar. If so, then, it must understand the option tag in order > to infer correct semantics from the REGISTER. Ideally, this would all be true. In practice, with the introduction of the Service-Route and Path mechanisms, we have invited proxies into the REGISTER transaction. And, for better or for worse, those particular cats are both well out of the bag and marking the furniture. > In some of your other posts, you seem to be arguing that we should not > and can not make any changes to a method semantics since this might > break intermediaries. However, we have done this in the past - take > everyone's favorite method REFER. With RFC 4488, we used a header > field and option tag to indicate that there will be no NOTIFY to the > REFER. This could potentially break an intermediary which sees the > REFER, only understands RFC 3515 which defines REFER, and expects to > see NOTIFYs. However, again, this is another case where an > intermediary is trying to infer semantics from a method, and as such, > it is effectively no longer a proxy and is now behaving like a UA and > must understand things like option tags, etc. The situation is somewhat different, in several important aspects. REFER is certainly not as fundamental to SIP as REGISTER is; and the change you're talking about was implemented to address a flaw in the original design of REFER. The consequence of intermediaries misinterpreting the new kind of REFER as the old kind was simply a timeout situation (which they would have code for), not potentially incorrect policy decisions. So, while there are some parallels, the key details are different. Finally, note that including a "Proxy-Require" in a request that has to travel across multiple domains of control -- like REFER -- is pretty much a guarantee that it won't ever work. Including it in something that is all within the same realm of control (e.g., that shared by an SSP and its customers) is far more tractable. So adding it to REFER would have been a poison pill. Adding it to REGISTER is simply prophylactic. But I agree with your analysis that the change to REFER that you cite has the potential to break intermediaries. It was chosen as a "least evil" compromise path. /a From adam@nostrum.com Fri Jan 8 07:18:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FBC3A67EA for ; Fri, 8 Jan 2010 07:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqns7af1M46s for ; Fri, 8 Jan 2010 07:18:33 -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 232E03A67B0 for ; Fri, 8 Jan 2010 07:18:32 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o08FIR2X062811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 09:18:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B474CC3.6080005@nostrum.com> Date: Fri, 08 Jan 2010 09:18:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B474677.9090803@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 15:18:34 -0000 On 1/8/10 9:02 AM, Hadriel Kaplan wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Friday, January 08, 2010 9:52 AM >> To: Hadriel Kaplan >> >> On 1/8/10 8:18 AM, Hadriel Kaplan wrote: >> >>> Right, and my point was that PUBLISH would need a Require/Proxy-Require >>> >> too. >> >> I don't think it does, because we're not changing the semantics of PUBLISH. >> > You're not changing the semantics of the PUBLISH, because it has almost no semantics to begin with. Everything "important/unique" about it is tied to the event package name and body. So you need a Req/P-Req to say "you must understand this event package to process this PUBLISH". > But that's true of every PUBLISH. It's inherent in the very definition of the PUBLISH method. To process any PUBLISH, you must understand the event package. There are several event packages, many of which are used with PUBLISH, and none of which make use of option tags. /a From HKaplan@acmepacket.com Fri Jan 8 08:34:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCB63A677C for ; Fri, 8 Jan 2010 08:34:28 -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 UnHUT6z9BtVC for ; Fri, 8 Jan 2010 08:34:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E61023A6810 for ; Fri, 8 Jan 2010 08:34:26 -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; Fri, 8 Jan 2010 11:34:23 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Jan 2010 11:34:23 -0500 From: Hadriel Kaplan To: Adam Roach Date: Fri, 8 Jan 2010 11:34:21 -0500 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqQddWvjKBuBtcAQ4Ck52F1llByxwACmFow Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B474677.9090803@nostrum.com> <4B474CC3.6080005@nostrum.com> In-Reply-To: <4B474CC3.6080005@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 16:34:28 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Friday, January 08, 2010 10:18 AM > To: Hadriel Kaplan > >> > >> On 1/8/10 8:18 AM, Hadriel Kaplan wrote: > > You're not changing the semantics of the PUBLISH, because it has almost > no semantics to begin with. Everything "important/unique" about it is > tied to the event package name and body. So you need a Req/P-Req to say > "you must understand this event package to process this PUBLISH". > > >=20 > But that's true of every PUBLISH. It's inherent in the very definition > of the PUBLISH method. To process any PUBLISH, you must understand the > event package. There are several event packages, many of which are used > with PUBLISH, and none of which make use of option tags. Sure, but I was talking about for the case of the "intermediary" proxy-ish = devices you were concerned about - i.e., devices which shall not be named. -hadriel From adam@nostrum.com Fri Jan 8 08:45:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D813A6816 for ; Fri, 8 Jan 2010 08:45:28 -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, 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 0HwLzFzLrodS for ; Fri, 8 Jan 2010 08:45:26 -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 82C143A677C for ; Fri, 8 Jan 2010 08:45:26 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o08GjLmj069752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 10:45:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B476121.5010708@nostrum.com> Date: Fri, 08 Jan 2010 10:45:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B474677.9090803@nostrum.com> <4B474CC3.6080005@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406010106070107020304" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 16:45:28 -0000 This is a multi-part message in MIME format. --------------020406010106070107020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/8/10 10:34 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Friday, January 08, 2010 10:18 AM >> To: Hadriel Kaplan >> >>>> On 1/8/10 8:18 AM, Hadriel Kaplan wrote: >>>> >>> You're not changing the semantics of the PUBLISH, because it has almost >>> >> no semantics to begin with. Everything "important/unique" about it is >> tied to the event package name and body. So you need a Req/P-Req to say >> "you must understand this event package to process this PUBLISH". >> >>> >> But that's true of every PUBLISH. It's inherent in the very definition >> of the PUBLISH method. To process any PUBLISH, you must understand the >> event package. There are several event packages, many of which are used >> with PUBLISH, and none of which make use of option tags. >> > Sure, but I was talking about for the case of the "intermediary" proxy-ish devices you were concerned about - i.e., devices which shall not be named. > > We're talking about different things. I'm talking about the behavior of intermediaries who don't have the first foggy clue about any of the extensions that come out of MARTINI, and who don't need to. When they see this NOTIFY, they have no chance of doing the wrong thing -- hence no backwards-compatibility issues. You're talking about the things that are hip-deep in this mess, and need to do MARTINI-ish things to work. And for them, all that's necessary is the ability to recognize what's going on. The combination of "PUBLISH" and "Event: reg" gets you 100% of the way there. /a --------------020406010106070107020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/8/10 10:34 AM, Hadriel Kaplan wrote: 

  
-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: Friday, January 08, 2010 10:18 AM
To: Hadriel Kaplan
    
On 1/8/10 8:18 AM, Hadriel Kaplan wrote:
        
You're not changing the semantics of the PUBLISH, because it has almost
      
no semantics to begin with.  Everything "important/unique" about it is
tied to the event package name and body.  So you need a Req/P-Req to say
"you must understand this event package to process this PUBLISH".
    
      
But that's true of every PUBLISH. It's inherent in the very definition
of the PUBLISH method. To process any PUBLISH, you must understand the
event package. There are several event packages, many of which are used
with PUBLISH, and none of which make use of option tags.
    
Sure, but I was talking about for the case of the "intermediary" proxy-ish devices you were concerned about - i.e., devices which shall not be named.

We're talking about different things.

I'm talking about the behavior of intermediaries who don't have the first foggy clue about any of the extensions that come out of MARTINI, and who don't need to. When they see this NOTIFY, they have no chance of doing the wrong thing -- hence no backwards-compatibility issues.

You're talking about the things that are hip-deep in this mess, and need to do MARTINI-ish things to work. And for them, all that's necessary is the ability to recognize what's going on. The combination of "PUBLISH" and "Event: reg" gets you 100% of the way there.

/a
--------------020406010106070107020304-- From john.elwell@siemens-enterprise.com Fri Jan 8 09:46:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5805A3A6809 for ; Fri, 8 Jan 2010 09:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVo+JFufN8ih for ; Fri, 8 Jan 2010 09:46:33 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 337E73A6840 for ; Fri, 8 Jan 2010 09:46:32 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-480526 for martini@ietf.org; Fri, 8 Jan 2010 18:46:30 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8CE2A1EB8293 for ; Fri, 8 Jan 2010 18:46:30 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Jan 2010 18:46:31 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Fri, 8 Jan 2010 18:46:29 +0100 Thread-Topic: Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQ== Message-ID: Keywords: MARTINI 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: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 17:46:34 -0000 Revised following the feedback since yesterday. Please continue the feedbac= k. - The mechanism MUST allow the PBX to be responsible for its AORs and to ha= ndle requests to those AORs according to its rules. - The mechanism MUST allow the PBX to receive requests to its AORs that ori= ginate off-PBX and arrive via the SSP, so that the PBX can handle those req= uests according to its rules. - The mechanism MUST provide a means whereby the PBX knows which of its AOR= s an inbound request is targeted at. - The mechanism MUST provide a means of avoiding problems due to one side u= sing the mechanism and the other side not. - The mechanism MUST observe SIP backwards compatibility principles. - The mechanism MUST work in the presence of intermediate "proxies" between= the PBX and the SSP's domain proxy, where those intermediate "proxies" nee= d to be on the path of inbound requests to the PBX. - The mechanism MUST work when the PBX obtains its IP address dynamically. - The mechanism MUST work without requiring the PBX to publish reachability= information through the DNS. Also some desiderata: - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing S= IP service to ordinary subscribers in order to provide a SIP trunking servi= ce to PBXs. - The mechanism SHOULD scale to PBXs of several thousand AORs. - The mechanism SHOULD require relatively modest changes to a substantial p= opulation of existing SSP and PBX implementations, in order to encourage a = fast market adoption of the standardized mechanism. John From bruno.chatras@orange-ftgroup.com Fri Jan 8 09:59:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D4D3A68BD for ; Fri, 8 Jan 2010 09:59:23 -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_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 kzzlcGcgX7fC for ; Fri, 8 Jan 2010 09:59:22 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 9AA913A68A3 for ; Fri, 8 Jan 2010 09:59:22 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E90B01340C7; Fri, 8 Jan 2010 18:59:19 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6F5A1238048; Fri, 8 Jan 2010 18:59:19 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 18:59:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 18:59:17 +0100 Message-ID: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQA1fbcw References: From: To: X-OriginalArrivalTime: 08 Jan 2010 17:59:19.0272 (UTC) FILETIME=[4CDAF680:01CA908C] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.8.172419 Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 17:59:23 -0000 You have included a requirement that the mechanism MUST work in the presenc= e of intermediate "proxies" between the PBX and the SSP's. Don't we need as= well a requirement about the presence of intermediate enterprise proxies b= etween the PBX and the SIP terminals, especially when considering inbound r= equests? > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : vendredi 8 janvier 2010 18:46 > =C0 : martini@ietf.org > Objet : [martini] Requirements - rev1 >=20 > Revised following the feedback since yesterday. Please=20 > continue the feedback. >=20 > - The mechanism MUST allow the PBX to be responsible for its=20 > AORs and to handle requests to those AORs according to its rules. > - The mechanism MUST allow the PBX to receive requests to its=20 > AORs that originate off-PBX and arrive via the SSP, so that=20 > the PBX can handle those requests according to its rules. > - The mechanism MUST provide a means whereby the PBX knows=20 > which of its AORs an inbound request is targeted at. > - The mechanism MUST provide a means of avoiding problems due=20 > to one side using the mechanism and the other side not. > - The mechanism MUST observe SIP backwards compatibility principles. > - The mechanism MUST work in the presence of intermediate=20 > "proxies" between the PBX and the SSP's domain proxy, where=20 > those intermediate "proxies" need to be on the path of=20 > inbound requests to the PBX. > - The mechanism MUST work when the PBX obtains its IP address=20 > dynamically. > - The mechanism MUST work without requiring the PBX to=20 > publish reachability information through the DNS. >=20 > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > for providing SIP service to ordinary subscribers in order to=20 > provide a SIP trunking service to PBXs. > - The mechanism SHOULD scale to PBXs of several thousand AORs. > - The mechanism SHOULD require relatively modest changes to a=20 > substantial population of existing SSP and PBX=20 > implementations, in order to encourage a fast market adoption=20 > of the standardized mechanism. >=20 > John >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Fri Jan 8 10:04:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB943A688D for ; Fri, 8 Jan 2010 10:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 jSv72disLj2d for ; Fri, 8 Jan 2010 10:04:05 -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 0D8F73A6803 for ; Fri, 8 Jan 2010 10:04:04 -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-480732; Fri, 8 Jan 2010 19:04:02 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8D6091EB8293; Fri, 8 Jan 2010 19:04:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 8 Jan 2010 19:04:02 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" Date: Fri, 8 Jan 2010 19:04:01 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQA1fbcwAAA8TsA= Message-ID: References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> 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: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:04:06 -0000 Bruno, Thanks. That is true, but during the SIPconnect work we have always conside= red the interface between the enterprise edge device and the SSP, and that = the enterprise edge device would register and supply the contact URIs. So i= t hasn't really been an issue. John=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 08 January 2010 17:59 > To: Elwell, John > Cc: martini@ietf.org > Subject: RE: [martini] Requirements - rev1 >=20 > You have included a requirement that the mechanism MUST work=20 > in the presence of intermediate "proxies" between the PBX and=20 > the SSP's. Don't we need as well a requirement about the=20 > presence of intermediate enterprise proxies between the PBX=20 > and the SIP terminals, especially when considering inbound requests? >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > > Envoy=E9 : vendredi 8 janvier 2010 18:46 > > =C0 : martini@ietf.org > > Objet : [martini] Requirements - rev1 > >=20 > > Revised following the feedback since yesterday. Please=20 > > continue the feedback. > >=20 > > - The mechanism MUST allow the PBX to be responsible for its=20 > > AORs and to handle requests to those AORs according to its rules. > > - The mechanism MUST allow the PBX to receive requests to its=20 > > AORs that originate off-PBX and arrive via the SSP, so that=20 > > the PBX can handle those requests according to its rules. > > - The mechanism MUST provide a means whereby the PBX knows=20 > > which of its AORs an inbound request is targeted at. > > - The mechanism MUST provide a means of avoiding problems due=20 > > to one side using the mechanism and the other side not. > > - The mechanism MUST observe SIP backwards compatibility principles. > > - The mechanism MUST work in the presence of intermediate=20 > > "proxies" between the PBX and the SSP's domain proxy, where=20 > > those intermediate "proxies" need to be on the path of=20 > > inbound requests to the PBX. > > - The mechanism MUST work when the PBX obtains its IP address=20 > > dynamically. > > - The mechanism MUST work without requiring the PBX to=20 > > publish reachability information through the DNS. > >=20 > > Also some desiderata: > > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > > for providing SIP service to ordinary subscribers in order to=20 > > provide a SIP trunking service to PBXs. > > - The mechanism SHOULD scale to PBXs of several thousand AORs. > > - The mechanism SHOULD require relatively modest changes to a=20 > > substantial population of existing SSP and PBX=20 > > implementations, in order to encourage a fast market adoption=20 > > of the standardized mechanism. > >=20 > > John > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > = From BLINDSAY@nortel.com Fri Jan 8 10:24:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFF63A688F for ; Fri, 8 Jan 2010 10:24:47 -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.001, 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 bzHjEyeMtOnN for ; Fri, 8 Jan 2010 10:24:46 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8B3153A688D for ; Fri, 8 Jan 2010 10:24:46 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o08IOZo26113; Fri, 8 Jan 2010 18:24:36 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_01CA908F.D2686D4A" Date: Fri, 8 Jan 2010 13:24:25 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> In-Reply-To: <4B476121.5010708@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: martini-shaken-implicit-registrations : propose P-Associated-URI be removed Thread-Index: AcqQggIdkxt7FOdoRKWYlLpwGWznCgACeJCg References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> From: "Brian Lindsay" To: "Hadriel Kaplan" , "Elwell, John" , "David Hancock" Cc: martini@ietf.org Subject: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:24:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA908F.D2686D4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hadriel / John / David, =20 Regarding the martini-shaken-implicit-registrations draft, currently the draft has the following requirement regarding support of P-Associated-URI: =20 The Registrar SHOULD indicate all of the implicitly Registered AoRs in a P-Associated-URI header field(s) in the 200 response to the REGISTER, if it supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? Should we document a legal/compliant means of indicating AoR username "wildcards"?]=20 As worded, this is a conditional SHOULD requirement (conditional on whether RFC 3455 is supported by the Registrar), but there is a question about whether PAU should be mandated. =20 My suggestion would be to remove this requirement altogether: * PAU is not widely utilized outside of IMS and hence is likely not part of most currently deployed SIP PBX registration-based solutions today * There haven't been any proposed requirements tabled to date that would drive inclusion of this * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there was a suggestion of making this optional, but I believe none of the enterprise vendors ever saw any strong value case for doing anything with the header, hence it was promptly removed and never re-surfaced as a requirement in subsequent drafts of the spec * There are diffferences between RFC 3455 definitions of PAU and IMS usage of the header that would need to be resolved in the draft * The assigned numbers for the SIP PBX already need to be communicated via other means oout of scope of the draft * There are other technical issues/considerations that would be resolved/considered if it was included, as articulated in Hadriel's summary slide package of the draft Making mandatory would raise a large number of questions and considerations, and the potential for implementing something in the network that would never be used by recipiants. It would seem prudent to simply remove from the draft altogether at this point. =20 Thanks Brian ------_=_NextPart_001_01CA908F.D2686D4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Hadriel / John / David,
 
   Regarding the=20 martini-shaken-implicit-registrations draft, currently the draft has the = following requirement regarding support of = P-Associated-URI:
 
 The = Registrar SHOULD=20 indicate all of the implicitly Registered AoRs in a = P-Associated-URI header=20 field(s) in the 200 response to the REGISTER, if it supports=20 [RFC3455].  [OPEN ISSUE: should we mandate PAU support?  = Should=20 we document a legal/compliant means of indicating AoR username=20 "wildcards"?]
    As worded, = this is a=20 conditional SHOULD requirement (conditional on whether RFC 3455 is=20 supported by the Registrar), but there is a question about whether PAU = should be=20 mandated.
 
   My suggestion would be to = remove this=20 requirement altogether:
  • PAU=20 is not widely utilized outside of IMS and hence is likely not part of = most=20 currently deployed SIP PBX registration-based solutions=20 today
  • There=20 haven't been any proposed requirements tabled to date that would drive = inclusion of this
  • In a=20 very early draft of SIP Connect 1.1 ( > 1.5 years ago), there = was a=20 suggestion of making this optional, but I believe none of the = enterprise=20 vendors ever saw any strong value case for doing anything with the = header,=20 hence it was promptly removed and never re-surfaced as a requirement = in=20 subsequent drafts of the spec
  • There=20 are diffferences between RFC 3455 definitions of PAU and IMS usage of = the=20 header that would need to be resolved in the = draft
  • The=20 assigned numbers for the SIP PBX already need to be communicated via = other=20 means oout of scope of the draft
  • There=20 are other technical issues/considerations that would be = resolved/considered if=20 it was included, as articulated in Hadriel's summary slide package of = the=20 draft
     Making mandatory would raise = a large=20 number of questions and considerations, and the potential for = implementing=20 something in the network that would never be used by recipiants. It = would=20 seem prudent to simply remove from the draft altogether at this=20 point.
 
    Thanks
       =20 Brian
------_=_NextPart_001_01CA908F.D2686D4A-- From HKaplan@acmepacket.com Fri Jan 8 10:30:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2D13A688F for ; Fri, 8 Jan 2010 10:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Vkvq6PHBWx5u for ; Fri, 8 Jan 2010 10:30:19 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 100FB3A689A for ; Fri, 8 Jan 2010 10:30:18 -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; Fri, 8 Jan 2010 13:30:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 8 Jan 2010 13:30:14 -0500 From: Hadriel Kaplan To: Brian Lindsay , "Elwell, John" , David Hancock Date: Fri, 8 Jan 2010 13:30:13 -0500 Thread-Topic: martini-shaken-implicit-registrations : propose P-Associated-URI be removed Thread-Index: AcqQggIdkxt7FOdoRKWYlLpwGWznCgACeJCgAAEXNXA= Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A58743DA1mail_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:30:25 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A58743DA1mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fine by me. I was thinking about this some as well, that if a PBX really did want this = info (for example for troubleshooting or whatever), it could get it from a = reg-event subscription if it supported that. (though I don't think I've eve= r seen a registering PBX subscribe for reg-event) -hadriel ________________________________ From: Brian Lindsay [mailto:blindsay@nortel.com] Sent: Friday, January 08, 2010 1:24 PM To: Hadriel Kaplan; Elwell, John; David Hancock Cc: martini@ietf.org Subject: martini-shaken-implicit-registrations : propose P-Associated-URI b= e removed Hi Hadriel / John / David, Regarding the martini-shaken-implicit-registrations draft, currently the= draft has the following requirement regarding support of P-Associated-URI: The Registrar SHOULD indicate all of the implicitly Registered AoRs in a P= -Associated-URI header field(s) in the 200 response to the REGISTER, if it = supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? Should we= document a legal/compliant means of indicating AoR username "wildcards"?] As worded, this is a conditional SHOULD requirement (conditional on whe= ther RFC 3455 is supported by the Registrar), but there is a question about= whether PAU should be mandated. My suggestion would be to remove this requirement altogether: * PAU is not widely utilized outside of IMS and hence is likely not part= of most currently deployed SIP PBX registration-based solutions today * There haven't been any proposed requirements tabled to date that would= drive inclusion of this * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there was= a suggestion of making this optional, but I believe none of the enterprise= vendors ever saw any strong value case for doing anything with the header,= hence it was promptly removed and never re-surfaced as a requirement in su= bsequent drafts of the spec * There are diffferences between RFC 3455 definitions of PAU and IMS usa= ge of the header that would need to be resolved in the draft * The assigned numbers for the SIP PBX already need to be communicated v= ia other means oout of scope of the draft * There are other technical issues/considerations that would be resolved= /considered if it was included, as articulated in Hadriel's summary slide p= ackage of the draft Making mandatory would raise a large number of questions and considera= tions, and the potential for implementing something in the network that wou= ld never be used by recipiants. It would seem prudent to simply remove from= the draft altogether at this point. Thanks Brian --_000_E6C2E8958BA59A4FB960963D475F7AC31A58743DA1mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fine by me.

I was thinking about this some as well= , that if a PBX really did want this info (for example for troubleshooting or whatever), it could get it from a reg-event subscription if it supported th= at. (though I don’t think I’ve ever seen a registering PBX subscrib= e for reg-event)

-hadriel

 

From: Brian Lindsay [mailto:blindsay@nortel.com]
Sent: Friday, January 08, 20= 10 1:24 PM
To: Hadriel Kaplan; Elwell, = John; David Hancock
Cc: martini@ietf.org
Subject: martini-shaken-implicit-registrations : propose P-Associated-URI be removed=

=  

Hi Hadriel / John / David,

=  

   Regarding the martini-shaken-implicit-registrations draft, currently the draft has the following requirement regarding support of P-Associated-URI:<= o:p>

=  

 The Registrar SHOULD indicate all of the im= plicitly Registered AoRs in a P-Associated-URI header field(s) in the 200 respo= nse to the REGISTER, if it supports [RFC3455].  [OPEN ISSUE: should w= e mandate PAU support?  Should we document a legal/compliant means of indicatin= g AoR username "wildcards"?]

    As worded, this is a conditional SHOULD requirement (conditional on whe= ther RFC 3455 is supported by the Registrar), but there is a question about whet= her PAU should be man= dated.

=  

   My suggestion would = be to remove this requirement altogether:

  • = PAU is not widely utilized outside of IMS and hence is likely= not part of most currently deployed SIP PBX registration-based soluti= ons today
  • There haven't = been any proposed requirements tabled to date that would drive inclusion of this
  • In a very earl= y draft of SIP Connect 1.1 ( > 1.5 years ago), there was a suggestion of making this optional, but I believe none of the enterpri= se vendors ever saw any strong value case for doing anything with the hea= der, hence it was promptly removed and never re-surfaced as a requirement i= n subsequent drafts of the spec
  • There are diffferences between RFC 3455 definitions of PAU and IMS usage of the header that would need to be resolved in the draft<= o:p>
  • The assigned n= umbers for the SIP PBX already need to be communicated via other means oout o= f scope of the draft
  • There are othe= r technical issues/considerations that would be resolved/considered if i= t was included, as articulated in Hadriel's summary slide package of the draft

     Making mandatory would raise a large number of questions and considerations, = and the potential for implementing something in the network that would nev= er be used by recipiants. It would seem prudent to simply remove from the draf= t altogether at this point.

=  

    Thanks

      &n= bsp; Brian

--_000_E6C2E8958BA59A4FB960963D475F7AC31A58743DA1mail_-- From david.middleton@nsn.com Fri Jan 8 10:43:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3333A68BE for ; Fri, 8 Jan 2010 10:43:10 -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 cRZzek++MXat for ; Fri, 8 Jan 2010 10:43:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EC9403A68B6 for ; Fri, 8 Jan 2010 10:43:08 -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 o08Ih1xb020210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2010 19:43:01 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o08IgwUr027902; Fri, 8 Jan 2010 19:43:00 +0100 Received: from USCHEXC006.nsn-intra.net ([10.159.160.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 19:42:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 12:42:22 -0600 Message-ID: <159B27ECF9D16E40BD7ABD5778522B0103BAABFE@USCHEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqPvqbokmgWEIVmRuONn1P1OE/4wwACmv8AADGq0IA= References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com> From: "Middleton, David (NSN - US/Boca Raton)" To: "ext Hadriel Kaplan" , "Adam Roach" , "Spencer Dawkins" X-OriginalArrivalTime: 08 Jan 2010 18:42:54.0509 (UTC) FILETIME=[63A875D0:01CA9092] Cc: martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:43:10 -0000 The statement ... > We already have a=20 > means of providing reachability information (Path),=20 > subsequent request routes (Service-Route), and NAT traversal=20 > (outbound) through a REGISTER transaction ... speaks volumes with respect to the capabilities that are built around REGISTER and the work that would be needed to use PUBLISH for reachability information. Redoing all of this (and future REGISTER-oriented enhancements) for PUBLISH does not make sense. Some security appliances (e.g. SBCs) protect the SP core by not allowing requests through from unregistered UAs. Applying security policies selectively based on the type of the PUBLISH is very expensive since the message must be parsed to the point of learning whether it is for reachability information or not. Opening the door to all PUBLISH messages would be very undesirable. Either way, it makes protection against DoS attacks more difficult. David =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of ext Hadriel Kaplan > Sent: Thursday, January 07, 2010 1:56 PM > To: Adam Roach; Spencer Dawkins > Cc: martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 >=20 > I don't understand why you think using a REGISTER transaction=20 > makes it any more or less architecture-specific than a PUBLISH one. =20 >=20 > No matter what, we're talking about providing reachability=20 > information for a group of AoR's, and the routing rules=20 > associated with that provided information. We already have a=20 > means of providing reachability information (Path),=20 > subsequent request routes (Service-Route), and NAT traversal=20 > (outbound) through a REGISTER transaction, just not for=20 > multiple AoR's. We can either update REGISTER to handle that=20 > latter issue, or modify PUBLISH to handle the former issues. =20 > The advantages of using a REGISTER are fairly obvious I would think: > 1) People already use them for this purpose today. > 2) We *are* actually registering something. > 3) My guess is it's less code changes. I know that's=20 > not an objective condition, but I bet it's true. Just=20 > imagine the features people have for controlling REGISTER=20 > storms, using them as keepalives, tying their state to=20 > policies, counting them and providing their stats, etc. =20 > Heck, I bet it's even easier for test equipment, since I know=20 > some of them have specific mechanisms for REGISTER generation=20 > that wouldn't need to change to test this thing. >=20 > -hadriel >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: Thursday, January 07, 2010 12:27 PM > > To: Spencer Dawkins > > Cc: Ben Campbell; Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] draft-roach-martini-up-00 > >=20 > > On 1/7/10 11:25, Jan 7, Spencer Dawkins wrote: > > > So, as a reality check ... deployed systems today are=20 > using implicit > > > registration with no indication that this is happening in the > > > signaling, but the fact that this isn't visible to intermediaries > > > today wasn't listed in Hadriel's problem statement draft. > > > > > > Is this an oversight? Is anyone encountering problems with > > > intermediaries in deployed systems using implicit=20 > registration today? > >=20 > > The fact that it works in a specific architecture says=20 > nothing about how > > it interacts with other architectures. The proposed changes=20 > to REGISTER > > are simply not backwards compatible with the protocol as it=20 > has already > > been defined. A change in semantics without an indicator=20 > that will alert > > all interested parties of the change in semantics is a recipe for > > disaster. And intermediaries are a party to REGISTER=20 > transactions, for > > better or for worse. > >=20 > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From pkyzivat@cisco.com Fri Jan 8 10:43:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A4A3A68B6 for ; Fri, 8 Jan 2010 10:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUzgjR6UMAmE for ; Fri, 8 Jan 2010 10:43: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 08A5C3A688F for ; Fri, 8 Jan 2010 10:43:33 -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: ApoEAIILR0tAZnwN/2dsb2JhbADBEokOB4pyhC8E X-IronPort-AV: E=Sophos;i="4.49,243,1262563200"; d="scan'208";a="79129561" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Jan 2010 18:43:31 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o08IhOi5021191; Fri, 8 Jan 2010 18:43:31 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 12:43:31 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 12:43:30 -0600 Message-ID: <4B477CCE.5080906@cisco.com> Date: Fri, 08 Jan 2010 13:43:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Lindsay References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 18:43:30.0955 (UTC) FILETIME=[7961ADB0:01CA9092] Cc: David Hancock , Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:43:35 -0000 I agree. This info can be learned more reliably using the reg event package. The PBX is probably going to want that anyway. Thanks, Paul Brian Lindsay wrote: > Hi Hadriel / John / David, > > Regarding the martini-shaken-implicit-registrations draft, currently > the draft has the following requirement regarding support of > P-Associated-URI: > > The Registrar SHOULD indicate all of the implicitly Registered AoRs in > a P-Associated-URI header field(s) in the 200 response to the REGISTER, > if it supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? > Should we document a legal/compliant means of indicating AoR username > "wildcards"?] > As worded, this is a conditional SHOULD requirement (conditional on > whether RFC 3455 is supported by the Registrar), but there is a question > about whether PAU should be mandated. > > My suggestion would be to remove this requirement altogether: > > * PAU is not widely utilized outside of IMS and hence is likely not > part of most currently deployed SIP PBX > registration-based solutions today > * There haven't been any proposed requirements tabled to date that > would drive inclusion of this > * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there > was a suggestion of making this optional, but I believe none of > the enterprise vendors ever saw any strong value case for doing > anything with the header, hence it was promptly removed and never > re-surfaced as a requirement in subsequent drafts of the spec > * There are diffferences between RFC 3455 definitions of PAU and IMS > usage of the header that would need to be resolved in the draft > * The assigned numbers for the SIP PBX already need to be > communicated via other means oout of scope of the draft > * There are other technical issues/considerations that would be > resolved/considered if it was included, as articulated in > Hadriel's summary slide package of the draft > > Making mandatory would raise a large number of questions and > considerations, and the potential for implementing something in the > network that would never be used by recipiants. It would seem prudent to > simply remove from the draft altogether at this point. > > Thanks > Brian > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Fri Jan 8 10:51:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37B33A688F for ; Fri, 8 Jan 2010 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.672, 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 JAyVpzUl7lsu for ; Fri, 8 Jan 2010 10:50:59 -0800 (PST) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by core3.amsl.com (Postfix) with ESMTP id EAE8F3A67F8 for ; Fri, 8 Jan 2010 10:50:58 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.137]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 10:50:56 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Paul Kyzivat'" , "'Brian Lindsay'" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> <4B477CCE.5080906@cisco.com> In-Reply-To: <4B477CCE.5080906@cisco.com> Date: Fri, 8 Jan 2010 10:51:25 -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: AcqQknZtVtrOG1JyRm+dwfjhVBgdygAARVAQ Content-Language: en-us X-OriginalArrivalTime: 08 Jan 2010 18:50:56.0687 (UTC) FILETIME=[830EFBF0:01CA9093] Cc: 'Hadriel Kaplan' , 'David Hancock' , martini@ietf.org Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:51:00 -0000 +1. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, January 08, 2010 10:43 AM To: Brian Lindsay Cc: David Hancock; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed I agree. This info can be learned more reliably using the reg event package. The PBX is probably going to want that anyway. Thanks, Paul Brian Lindsay wrote: > Hi Hadriel / John / David, > > Regarding the martini-shaken-implicit-registrations draft, currently > the draft has the following requirement regarding support of > P-Associated-URI: > > The Registrar SHOULD indicate all of the implicitly Registered AoRs in > a P-Associated-URI header field(s) in the 200 response to the REGISTER, > if it supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? > Should we document a legal/compliant means of indicating AoR username > "wildcards"?] > As worded, this is a conditional SHOULD requirement (conditional on > whether RFC 3455 is supported by the Registrar), but there is a question > about whether PAU should be mandated. > > My suggestion would be to remove this requirement altogether: > > * PAU is not widely utilized outside of IMS and hence is likely not > part of most currently deployed SIP PBX > registration-based solutions today > * There haven't been any proposed requirements tabled to date that > would drive inclusion of this > * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there > was a suggestion of making this optional, but I believe none of > the enterprise vendors ever saw any strong value case for doing > anything with the header, hence it was promptly removed and never > re-surfaced as a requirement in subsequent drafts of the spec > * There are diffferences between RFC 3455 definitions of PAU and IMS > usage of the header that would need to be resolved in the draft > * The assigned numbers for the SIP PBX already need to be > communicated via other means oout of scope of the draft > * There are other technical issues/considerations that would be > resolved/considered if it was included, as articulated in > Hadriel's summary slide package of the draft > > Making mandatory would raise a large number of questions and > considerations, and the potential for implementing something in the > network that would never be used by recipiants. It would seem prudent to > simply remove from the draft altogether at this point. > > Thanks > Brian > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From richard@shockey.us Fri Jan 8 12:29:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3963A6835 for ; Fri, 8 Jan 2010 12:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.692, 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 m42FEUzT0-Il for ; Fri, 8 Jan 2010 12:29:56 -0800 (PST) Received: from outbound-mail-32.bluehost.com (outbound-mail-32.bluehost.com [69.89.18.152]) by core3.amsl.com (Postfix) with SMTP id BEF213A67C0 for ; Fri, 8 Jan 2010 12:29:56 -0800 (PST) Received: (qmail 17734 invoked by uid 0); 8 Jan 2010 20:29:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy2.bluehost.com with SMTP; 8 Jan 2010 20:29:54 -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=lWIIv23vH9HH+Dk1VH6Q+0g0qEHYsh3hLnvlFNRn0sEDvVAgTvUJWqDttyyuOECQJ7Cq0Z7ggZ1nXIrc3mnJJEUTODW60X66Q4X4fGsiC81FmO6gb/WIRusQj4ZGeSpR; 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 1NTLT0-0008OS-LA for martini@ietf.org; Fri, 08 Jan 2010 13:29:54 -0700 From: "Richard Shockey" To: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> <4B477CCE.5080906@cisco.com> In-Reply-To: Date: Fri, 8 Jan 2010 15:29:46 -0500 Message-ID: <014001ca90a1$51e99f40$f5bcddc0$@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: AcqQknZtVtrOG1JyRm+dwfjhVBgdygAARVAQAANwHDA= 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} Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 20:29:57 -0000 +1 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Bernard Aboba > Sent: Friday, January 08, 2010 1:51 PM > To: 'Paul Kyzivat'; 'Brian Lindsay' > Cc: 'Hadriel Kaplan'; 'David Hancock'; martini@ietf.org > Subject: Re: [martini] martini-shaken-implicit-registrations : propose > P-Associated-URI be removed > > +1. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, January 08, 2010 10:43 AM > To: Brian Lindsay > Cc: David Hancock; Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] martini-shaken-implicit-registrations : propose > P-Associated-URI be removed > > I agree. This info can be learned more reliably using the reg event > package. The PBX is probably going to want that anyway. > > Thanks, > Paul > > Brian Lindsay wrote: > > Hi Hadriel / John / David, > > > > Regarding the martini-shaken-implicit-registrations draft, > currently > > the draft has the following requirement regarding support of > > P-Associated-URI: > > > > The Registrar SHOULD indicate all of the implicitly Registered AoRs > in > > a P-Associated-URI header field(s) in the 200 response to the > REGISTER, > > if it supports [RFC3455]. [OPEN ISSUE: should we mandate PAU > support? > > Should we document a legal/compliant means of indicating AoR > username > > "wildcards"?] > > As worded, this is a conditional SHOULD requirement (conditional > on > > whether RFC 3455 is supported by the Registrar), but there is a > question > > about whether PAU should be mandated. > > > > My suggestion would be to remove this requirement altogether: > > > > * PAU is not widely utilized outside of IMS and hence is likely > not > > part of most currently deployed SIP PBX > > registration-based solutions today > > * There haven't been any proposed requirements tabled to date > that > > would drive inclusion of this > > * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), > there > > was a suggestion of making this optional, but I believe none > of > > the enterprise vendors ever saw any strong value case for > doing > > anything with the header, hence it was promptly removed and > never > > re-surfaced as a requirement in subsequent drafts of the spec > > * There are diffferences between RFC 3455 definitions of PAU and > IMS > > usage of the header that would need to be resolved in the > draft > > * The assigned numbers for the SIP PBX already need to be > > communicated via other means oout of scope of the draft > > * There are other technical issues/considerations that would be > > resolved/considered if it was included, as articulated in > > Hadriel's summary slide package of the draft > > > > Making mandatory would raise a large number of questions and > > considerations, and the potential for implementing something in the > > network that would never be used by recipiants. It would seem > prudent to > > simply remove from the draft altogether at this point. > > > > Thanks > > Brian > > > > > > -------------------------------------------------------------------- > ---- > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Jan 8 13:19:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EF63A68ED for ; Fri, 8 Jan 2010 13:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.296 X-Spam-Level: X-Spam-Status: No, score=-10.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwR3By5kA+ji for ; Fri, 8 Jan 2010 13:19:27 -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 32FB73A68EB for ; Fri, 8 Jan 2010 13:19:27 -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: ApoEAJUwR0urRN+K/2dsb2JhbADBUpQLhC8E X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208";a="72043012" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Jan 2010 21:19:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o08LJPdx009337; Fri, 8 Jan 2010 21:19:25 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 15:19:25 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 15:19:25 -0600 Message-ID: <4B47A15C.4050708@cisco.com> Date: Fri, 08 Jan 2010 16:19:24 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> <4B474C3F.7090601@nostrum.com> In-Reply-To: <4B474C3F.7090601@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 21:19:25.0130 (UTC) FILETIME=[40E782A0:01CA90A8] Cc: Alan Johnston , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:19:28 -0000 Adam Roach wrote: > On 1/8/10 8:52 AM, Alan Johnston wrote: >> My point was that an intermediary "proxy" should not try to infer any >> semantics from a REGISTER - not that one can not imagine an >> architecture where this could break things. The REGISTER method is >> between the UA and the Registrar, and I don't recall anything in >> Section 16 of RFC 3261 behavior (which defines a SIP proxy) that is >> REGISTER specific. >> >> If this "proxy" is trying to infer semantics from a REGISTER, then it >> is effectively no longer a proxy (per RFC 3261) but instead is acting >> a Registrar. If so, then, it must understand the option tag in order >> to infer correct semantics from the REGISTER. > > Ideally, this would all be true. In practice, with the introduction of > the Service-Route and Path mechanisms, we have invited proxies into the > REGISTER transaction. And, for better or for worse, those particular > cats are both well out of the bag and marking the furniture. Yes. IMS is the poster child here. The P-CSCF and I-CSCF are heavily coupled to REGISTER. They typically are B2BUAs rather than proxies I think, but they try to pretend to be proxy-like. In any case, everybody and his brother seem to think that intermediate devices should be able to make decisions about who can and can't receive traffic based on whether they are registered or not. IMO that is a terrible concept, but still it is there. Thanks, Paul >> In some of your other posts, you seem to be arguing that we should not >> and can not make any changes to a method semantics since this might >> break intermediaries. However, we have done this in the past - take >> everyone's favorite method REFER. With RFC 4488, we used a header >> field and option tag to indicate that there will be no NOTIFY to the >> REFER. This could potentially break an intermediary which sees the >> REFER, only understands RFC 3515 which defines REFER, and expects to >> see NOTIFYs. However, again, this is another case where an >> intermediary is trying to infer semantics from a method, and as such, >> it is effectively no longer a proxy and is now behaving like a UA and >> must understand things like option tags, etc. > > The situation is somewhat different, in several important aspects. REFER > is certainly not as fundamental to SIP as REGISTER is; and the change > you're talking about was implemented to address a flaw in the original > design of REFER. The consequence of intermediaries misinterpreting the > new kind of REFER as the old kind was simply a timeout situation (which > they would have code for), not potentially incorrect policy decisions. > So, while there are some parallels, the key details are different. > > Finally, note that including a "Proxy-Require" in a request that has to > travel across multiple domains of control -- like REFER -- is pretty > much a guarantee that it won't ever work. Including it in something that > is all within the same realm of control (e.g., that shared by an SSP and > its customers) is far more tractable. So adding it to REFER would have > been a poison pill. Adding it to REGISTER is simply prophylactic. > > But I agree with your analysis that the change to REFER that you cite > has the potential to break intermediaries. It was chosen as a "least > evil" compromise path. > > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Fri Jan 8 13:20:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71B03A68F5 for ; Fri, 8 Jan 2010 13:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dvpa78FZRIb8 for ; Fri, 8 Jan 2010 13:20:22 -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 F3DE33A68F1 for ; Fri, 8 Jan 2010 13:20: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: ApoEAJUwR0urRN+J/2dsb2JhbADBUpQLhC8E X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208";a="72043409" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 08 Jan 2010 21:20:19 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o08LKJ1p016612; Fri, 8 Jan 2010 21:20:19 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 15:20:19 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 15:20:18 -0600 Message-ID: <4B47A193.4080805@cisco.com> Date: Fri, 08 Jan 2010 16:20:19 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jan 2010 21:20:18.0885 (UTC) FILETIME=[60F1DF50:01CA90A8] Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 21:20:23 -0000 Elwell, John wrote: > I think Christer's summary is good. The architecture that Keith and others are talking about is applicable outside IMS too - that is what the SIP Forum is trying to achieve with SIPconnect - a means for a PBX to register. This was probably a lot clearer with the earlier domain registration draft ("stirred"), but it is still the same principle with the current implicit registration draft ("shaken"). Yes, it is certainly an approach that has popularity beyond IMS. Thanks, Paul > John > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: 07 January 2010 22:49 >> To: Christer Holmberg >> Cc: martini@ietf.org; Hadriel Kaplan >> Subject: Re: [martini] draft-roach-martini-up-00 >> >> You're spot on in describing the differences in perspectives. >> I think it >> comes down to whether you see an application for SIP outside of IMS >> architectures. >> >> In IMS-derived architectures, you can make the assumptions >> Keith has. In >> the general case, I don't think they hold. >> >> /a >> >> On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: >>> Hi, >>> >>> I think one of the reason we go over the same thing over >> and over is because we don't have a common view on the "user" concept. >>> Adam talks about multiple users, and that using a single >> REGISTER for those breaks things. Keith (and maybe others) >> seems to be arguing that we are still talking about a SINGLE >> SIP user. What happens inside the PBX is irrelevant. The PBX >> users have a relation with the PBX - the PBX has a relation >> with the SIP network. >>> So, from Keith's perspective things would not be broken, >> and intermediates in the SIP network do not (at least not by >> default) need to be aware of individual users behind the PBX. >>> But, I may have missunderstood, and in that case I appologize :) >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Original Message----- >>> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >>> Sent: 8. tammikuuta 2010 0:23 >>> To: Hadriel Kaplan >>> Cc: martini@ietf.org >>> Subject: Re: [martini] draft-roach-martini-up-00 >>> >>> On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: >>> >>>> I don't understand why you think using a REGISTER >> transaction makes it any more or less architecture-specific >> than a PUBLISH one. >>>> >>> That's not what I'm saying. There's been a lot of >> back-and-forth on this topic that amounts to the same >> exchange over and over (not just with you; with several >> parties). I'm going to replay the dialog in simplified form, >> because I think something is getting lost with the flood of email >>> messages: >>> >>> A: "Changing REGISTER in this way can break intermediaries." >>> B: "But in the architecture MARTINI is considering, it >> breaks nothing." >>> A: "The fact that it works in one place does not mean it >> works everywhere." >>> Changing the established meaning of REGISTER can cause >> problems unless all parties to the transaction understand the >> changes. The fact that no such problem arises in one specific >> architecture seems to be held out as proof that it must work >> everywhere. Which is the logical equivalent to: >>> "this particular swan is white, therefore all swans must be >> white." (cf >> http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori >> cal_inference) >>> What I'm proposing with PUBLISH isn't a change to >> established semantics. >>> In fact, it aligns precisely with established semantics: as >> I said on the phone, the basic concept of using PUBLISH to >> update a Location Service database could be a BCP, since it >> requires no new protocol mechanism. Nothing breaks, since the >> meaning of everything remains the same. >>> Everything else I've proposed so far is properly negotiated >> SIP protocol extensions using established extension >> mechanisms. You could do the same thing with REGISTER, if you >> really wanted to, by using both Require and Proxy-Require. >>> /a >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From drage@alcatel-lucent.com Fri Jan 8 15:38:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF5D3A6778 for ; Fri, 8 Jan 2010 15:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=-0.833, 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 sKqjcQBNLSYK for ; Fri, 8 Jan 2010 15:38:53 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id B22F53A6407 for ; Fri, 8 Jan 2010 15:38:52 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o08NckuF008403 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 00:38:46 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 9 Jan 2010 00:38:46 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "martini@ietf.org" Date: Sat, 9 Jan 2010 00:38:44 +0100 Thread-Topic: Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQBBWjVA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: 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: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 23:38:53 -0000 I would like to see a SHOULD on something like: The mechansism should allow handling of inbound requests and outbound reque= sts between SSP and PBX to be as common as possible as for a normal peering= arrangement (e.g. RFC 3263 based), as far as the PBX is concerned. The han= ding of requests at the incoming / outgoing gateway in the edge PBX should = be common once the mechanism has been applied. Essentially this means that the Request-URI should not be replaced by the S= SP on requests sent to the PBX. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, January 08, 2010 5:46 PM > To: martini@ietf.org > Subject: [martini] Requirements - rev1 >=20 > Revised following the feedback since yesterday. Please=20 > continue the feedback. >=20 > - The mechanism MUST allow the PBX to be responsible for its=20 > AORs and to handle requests to those AORs according to its rules. > - The mechanism MUST allow the PBX to receive requests to its=20 > AORs that originate off-PBX and arrive via the SSP, so that=20 > the PBX can handle those requests according to its rules. > - The mechanism MUST provide a means whereby the PBX knows=20 > which of its AORs an inbound request is targeted at. > - The mechanism MUST provide a means of avoiding problems due=20 > to one side using the mechanism and the other side not. > - The mechanism MUST observe SIP backwards compatibility principles. > - The mechanism MUST work in the presence of intermediate=20 > "proxies" between the PBX and the SSP's domain proxy, where=20 > those intermediate "proxies" need to be on the path of=20 > inbound requests to the PBX. > - The mechanism MUST work when the PBX obtains its IP address=20 > dynamically. > - The mechanism MUST work without requiring the PBX to=20 > publish reachability information through the DNS. >=20 > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > for providing SIP service to ordinary subscribers in order to=20 > provide a SIP trunking service to PBXs. > - The mechanism SHOULD scale to PBXs of several thousand AORs. > - The mechanism SHOULD require relatively modest changes to a=20 > substantial population of existing SSP and PBX=20 > implementations, in order to encourage a fast market adoption=20 > of the standardized mechanism. >=20 > John >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From drage@alcatel-lucent.com Fri Jan 8 15:47:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1754D3A6407 for ; Fri, 8 Jan 2010 15:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[AWL=1.231, 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 U0eQCAr+CL2B for ; Fri, 8 Jan 2010 15:47:55 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id D9E253A6405 for ; Fri, 8 Jan 2010 15:47:54 -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 o08NlpWd020091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 00:47:51 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 9 Jan 2010 00:47:51 +0100 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange-ftgroup.com" , "john.elwell@siemens-enterprise.com" Date: Sat, 9 Jan 2010 00:45:41 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQA1fbcwAAwt5KA= Message-ID: References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 23:47:56 -0000 With regard to the intermediate proxies requirement, can we limit this to i= ntermediate proxies in the SSP. For the PBX side, I have always considered an such mechanism as local to th= e gateway provided by the PBX, and not extending any further into the enter= prise. If this applies, then it excludes any proxies on the PBX side of the= gateway. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Friday, January 08, 2010 5:59 PM > To: john.elwell@siemens-enterprise.com > Cc: martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > You have included a requirement that the mechanism MUST work=20 > in the presence of intermediate "proxies" between the PBX and=20 > the SSP's. Don't we need as well a requirement about the=20 > presence of intermediate enterprise proxies between the PBX=20 > and the SIP terminals, especially when considering inbound requests? >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Elwell,=20 > John Envoy=E9 :=20 > > vendredi 8 janvier 2010 18:46 =C0 : martini@ietf.org Objet :=20 > [martini]=20 > > Requirements - rev1 > >=20 > > Revised following the feedback since yesterday. Please continue the=20 > > feedback. > >=20 > > - The mechanism MUST allow the PBX to be responsible for=20 > its AORs and=20 > > to handle requests to those AORs according to its rules. > > - The mechanism MUST allow the PBX to receive requests to its AORs=20 > > that originate off-PBX and arrive via the SSP, so that the PBX can=20 > > handle those requests according to its rules. > > - The mechanism MUST provide a means whereby the PBX knows which of=20 > > its AORs an inbound request is targeted at. > > - The mechanism MUST provide a means of avoiding problems=20 > due to one=20 > > side using the mechanism and the other side not. > > - The mechanism MUST observe SIP backwards compatibility principles. > > - The mechanism MUST work in the presence of intermediate "proxies"=20 > > between the PBX and the SSP's domain proxy, where those=20 > intermediate=20 > > "proxies" need to be on the path of inbound requests to the PBX. > > - The mechanism MUST work when the PBX obtains its IP address=20 > > dynamically. > > - The mechanism MUST work without requiring the PBX to publish=20 > > reachability information through the DNS. > >=20 > > Also some desiderata: > > - The mechanism SHOULD allow SSPs to exploit its mechanisms for=20 > > providing SIP service to ordinary subscribers in order to provide a=20 > > SIP trunking service to PBXs. > > - The mechanism SHOULD scale to PBXs of several thousand AORs. > > - The mechanism SHOULD require relatively modest changes to a=20 > > substantial population of existing SSP and PBX implementations, in=20 > > order to encourage a fast market adoption of the standardized=20 > > mechanism. > >=20 > > John > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From adam@nostrum.com Fri Jan 8 15:48:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CD03A6407 for ; Fri, 8 Jan 2010 15:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5jEFL9IULG-t for ; Fri, 8 Jan 2010 15:48:24 -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 2034B3A6405 for ; Fri, 8 Jan 2010 15:48:23 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o08NmJZt000932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 17:48:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B47C443.6060702@nostrum.com> Date: Fri, 08 Jan 2010 17:48:19 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 23:48:25 -0000 On 1/8/10 5:38 PM, DRAGE, Keith (Keith) wrote: > I would like to see a SHOULD on something like: > > The mechansism should allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as for a normal peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned. The handing of requests at the incoming / outgoing gateway in the edge PBX should be common once the mechanism has been applied. > > Essentially this means that the Request-URI should not be replaced by the SSP on requests sent to the PBX. > No, I don't think this is correct. Fundamentally, this is a 3261 registrar relationship (regardless of whether we use NOTIFY or REGISTER), not a 3263 relationship. In particular, what you propose cannot co-exist with the requirement: - The mechanism MUST provide a means of avoiding problems dueto one side using the mechanism and the other side not. Because a failure to rewrite the URI means that the URI will still resolve to the SSP under 3263 rules (since that's how it got there in the first place). So, if it sends it to the PBX, and the PBX doesn't use the MARTINI mechanism, it will apply 3263, and route it back to the SSP. The SSP will then apply MARTINI rules and route it to the registered PBX. Who will route it to the SSP. Which will then route it to the PBX. And so on. In particular, I think what you're describing is a requirement, but it should be "MUST NOT", instead of SHOULD." /a From drage@alcatel-lucent.com Fri Jan 8 15:54:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7483A65A5 for ; Fri, 8 Jan 2010 15:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=1.143, 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 1hdx38U-70mF for ; Fri, 8 Jan 2010 15:54:32 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 6CFD43A6407 for ; Fri, 8 Jan 2010 15:54:31 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o08NsQK7009614 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 00:54:28 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 9 Jan 2010 00:54:26 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Sat, 9 Jan 2010 00:54:25 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqQvRDGHWmdKtZcToemx3rq5LuPsAAAGSHg Message-ID: References: <4B47C443.6060702@nostrum.com> In-Reply-To: <4B47C443.6060702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 23:54:33 -0000 And here is where we start having the difference in philosophy. The correct mechanism for connecting two networks together is to peer them,= i.e. requests-URIs are not normally rewritten. That therefore should be the starting point of what PBXs have implemented. What we are then looking for is something that makes the life of the SSPs e= asier in some circumstances regarding configuration, to support such an int= erface. To me, that means bolting "the mechanism" as an add on, across that= gateway. Therefore we should leave the bits that are not the add-on as lik= e normal DNS / ENUM operation as possible. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Friday, January 08, 2010 11:48 PM > To: DRAGE, Keith (Keith) > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/8/10 5:38 PM, DRAGE, Keith (Keith) wrote: > > I would like to see a SHOULD on something like: > > > > The mechansism should allow handling of inbound requests=20 > and outbound requests between SSP and PBX to be as common as=20 > possible as for a normal peering arrangement (e.g. RFC 3263=20 > based), as far as the PBX is concerned. The handing of=20 > requests at the incoming / outgoing gateway in the edge PBX=20 > should be common once the mechanism has been applied. > > > > Essentially this means that the Request-URI should not be=20 > replaced by the SSP on requests sent to the PBX. > > =20 >=20 > No, I don't think this is correct. >=20 > Fundamentally, this is a 3261 registrar relationship=20 > (regardless of whether we use NOTIFY or REGISTER), not a 3263=20 > relationship. In particular, what you propose cannot co-exist=20 > with the requirement: >=20 > - The mechanism MUST provide a means of avoiding problems=20 > dueto one side using the mechanism and the other side not. >=20 >=20 > Because a failure to rewrite the URI means that the URI will=20 > still resolve to the SSP under 3263 rules (since that's how=20 > it got there in the first place). So, if it sends it to the=20 > PBX, and the PBX doesn't use the MARTINI mechanism, it will=20 > apply 3263, and route it back to the SSP.=20 > The SSP will then apply MARTINI rules and route it to the=20 > registered PBX. Who will route it to the SSP. Which will then=20 > route it to the PBX. >=20 > And so on. >=20 > In particular, I think what you're describing is a=20 > requirement, but it should be "MUST NOT", instead of SHOULD." >=20 > /a > = From adam@nostrum.com Fri Jan 8 16:18:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673043A67CF for ; Fri, 8 Jan 2010 16:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 FkenQx8oLEdx for ; Fri, 8 Jan 2010 16:18:25 -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 7EFB03A6407 for ; Fri, 8 Jan 2010 16:18:25 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o090ILAe003149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 18:18:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B47CB4D.8060804@nostrum.com> Date: Fri, 08 Jan 2010 18:18:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4B47C443.6060702@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:18:27 -0000 On 1/8/10 5:54 PM, DRAGE, Keith (Keith) wrote: > And here is where we start having the difference in philosophy. > I think we're more closely aligned in philosophy than you believe. We've just drawn different conclusions. For example: I agree, in as strong terms as possible, with the following statement: > The correct mechanism for connecting two networks together is to peer them, i.e. requests-URIs are not normally rewritten. > Yes! The correct way to do this is 3263 routing! I can't agree more! > That therefore should be the starting point of what PBXs have implemented. > That would be great! It would also be a different reality, apparently. MARTINI's very existence is predicated on the assertion that there are PBXes and/or SSPs out there that don't -- and for unstated reasons apparently won't ever -- properly implement peering using 3263 rules. Starting from the position that they should have done so is tilting at windmills. > What we are then looking for is something that makes the life of the SSPs easier in some circumstances regarding configuration, to support such an interface. To me, that means bolting "the mechanism" as an add on, across that gateway. Therefore we should leave the bits that are not the add-on as like normal DNS / ENUM operation as possible. > Ah, see here's what I'm talking about -- same philosophy, different conclusions. We both believe that the correct way to do this is with 3263. But you conclude that the best thing to do is split the baby by making a Location Sever DB/3263 hybrid. I've concluded that the dynamic approach, despite it being the wrong tool, is more closely modeled by the dynamic location mechanisms we already have in SIP -- so, the associated routing procedures should most closely mimic that. I can clearly describe what goes wrong, in a very real sense, with your proposal. We would need to solve the looping problem if we go down the path you're advocating. Which, even if it is a tractable problem to solve, is still one more problem you are choosing to introduce into the situation. /a From drage@alcatel-lucent.com Fri Jan 8 16:19:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9CD3A67CF for ; Fri, 8 Jan 2010 16:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 XBp6KommlYgp for ; Fri, 8 Jan 2010 16:19:44 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E3D4B3A6407 for ; Fri, 8 Jan 2010 16:19:43 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o090JU7D012630 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 01:19:31 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 9 Jan 2010 01:19:30 +0100 From: "DRAGE, Keith (Keith)" To: Brian Lindsay , Hadriel Kaplan , "Elwell, John" , David Hancock Date: Sat, 9 Jan 2010 01:19:28 +0100 Thread-Topic: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed Thread-Index: AcqQggIdkxt7FOdoRKWYlLpwGWznCgACeJCgAA0a6UA= Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE209DCD4DCFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:19:46 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE209DCD4DCFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the moment, from the IMS perspective, both mechanisms are there and can = be used FOR THE APPROPRIATE PURPOSE. From the IMS perspective, the only mec= hanism which will tell you which URIs are currently registered is reg-event= . Because IMS always works in association with authentication, if URIs are de= registered, then other things are going to stop working as well, so for exa= mple outgoing requests from a deregistered URI may well not work. Also note= that because the implicit registration set is a whole, it is unlikely indi= vidual URIs from the implicit registration set will disappear. You will eit= her lose them all or none of them. Because of this I can envisage that a pe= rfectly workable solution uses neither of these mechanisms. Note that IMS does intend that certain reg event values do cause the UA to = recognise a failure and initiate a reregistration. In the absence of this, = the interconnect will be broken in both directions, because the IMS has tak= en away its support for those URIs at that point. How many registrars outside IMS support reg event? Is it common? I would note also that none of John's current list of requirements needs su= ch a mechanism at all. So if people see the need for any such mechanism to = be mandated, they need to start exploring what the requirements would be. regards Keith ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Brian Lindsay Sent: Friday, January 08, 2010 6:24 PM To: Hadriel Kaplan; Elwell, John; David Hancock Cc: martini@ietf.org Subject: [martini] martini-shaken-implicit-registrations : propose P-Associ= ated-URI be removed Hi Hadriel / John / David, Regarding the martini-shaken-implicit-registrations draft, currently the= draft has the following requirement regarding support of P-Associated-URI: The Registrar SHOULD indicate all of the implicitly Registered AoRs in a P= -Associated-URI header field(s) in the 200 response to the REGISTER, if it = supports [RFC3455]. [OPEN ISSUE: should we mandate PAU support? Should we= document a legal/compliant means of indicating AoR username "wildcards"?] As worded, this is a conditional SHOULD requirement (conditional on whe= ther RFC 3455 is supported by the Registrar), but there is a question about= whether PAU should be mandated. My suggestion would be to remove this requirement altogether: * PAU is not widely utilized outside of IMS and hence is likely not part= of most currently deployed SIP PBX registration-based solutions today * There haven't been any proposed requirements tabled to date that would= drive inclusion of this * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there was= a suggestion of making this optional, but I believe none of the enterprise= vendors ever saw any strong value case for doing anything with the header,= hence it was promptly removed and never re-surfaced as a requirement in su= bsequent drafts of the spec * There are diffferences between RFC 3455 definitions of PAU and IMS usa= ge of the header that would need to be resolved in the draft * The assigned numbers for the SIP PBX already need to be communicated v= ia other means oout of scope of the draft * There are other technical issues/considerations that would be resolved= /considered if it was included, as articulated in Hadriel's summary slide p= ackage of the draft Making mandatory would raise a large number of questions and considera= tions, and the potential for implementing something in the network that wou= ld never be used by recipiants. It would seem prudent to simply remove from= the draft altogether at this point. Thanks Brian --_000_EDC0A1AE77C57744B664A310A0B23AE209DCD4DCFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
At the moment, from the IMS perspective, both mech= anisms=20 are there and can be used FOR THE APPROPRIATE PURPOSE. From the IMS perspec= tive,=20 the only mechanism which will tell you which URIs are currently registered = is=20 reg-event.
 
Because IMS always works in association with=20 authentication, if URIs are deregistered, then other things are going to st= op=20 working as well, so for example outgoing requests from a deregistered URI m= ay=20 well not work. Also note that because the implicit registration set is a wh= ole,=20 it is unlikely individual URIs from the implicit registration set will=20 disappear. You will either lose them all or none of them. Because of this I= can=20 envisage that a perfectly workable solution uses neither of these=20 mechanisms.
 
Note that IMS does intend that certain reg event v= alues do=20 cause the UA to recognise a failure and initiate a reregistration. In the=20 absence of this, the interconnect will be broken in both directions, becaus= e the=20 IMS has taken away its support for those URIs at that point.<= /DIV>
 
How many registrars outside IMS support reg event?= Is it=20 common?
 
I would note also that none of John's current list= of=20 requirements needs such a mechanism at all. So if people see the need for a= ny=20 such mechanism to be mandated, they need to start exploring what the=20 requirements would be.
 
regards
 
Keith

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Brian=20 Lindsay
Sent: Friday, January 08, 2010 6:24 PM
To: Ha= driel=20 Kaplan; Elwell, John; David Hancock
Cc:=20 martini@ietf.org
Subject: [martini]=20 martini-shaken-implicit-registrations : propose P-Associated-URI be=20 removed

Hi=20 Hadriel / John / David,
 
   Regarding the=20 martini-shaken-implicit-registrations draft, currently the draft has the= =20 following requirement regarding support of=20 P-Associated-URI:
 
 The Regist= rar=20 SHOULD indicate all of the implicitly Registered AoRs in a=20 P-Associated-URI header field(s) in the 200 response to the REGISTER, if = it=20 supports [RFC3455].  [OPEN ISSUE: should we mandate PAU=20 support?  Should we document a legal/compliant means of indicat= ing=20 AoR username "wildcards"?]
    As worded, this is&nbs= p;a=20 conditional SHOULD requirement (conditional on whether RFC 3455 is=20 supported by the Registrar), but there is a question about whether PAU sh= ould=20 be mandated.
 
   My suggestion would be to re= move=20 this requirement altogether:
  • PAU=20 is not widely utilized outside of IMS and hence is likely not part of m= ost=20 currently deployed SIP PBX registration-based solutions=20 today=20
  • There haven't been any proposed requirements tabled to date th= at=20 would drive inclusion of this=20
  • In=20 a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there= was=20 a suggestion of making this optional, but I believe none of the enterpr= ise=20 vendors ever saw any strong value case for doing anything with the head= er,=20 hence it was promptly removed and never re-surfaced as a requirement in= =20 subsequent drafts of the spec=20
  • There are diffferences between RFC 3455 definitions of PAU and= IMS=20 usage of the header that would need to be resolved in the=20 draft=20
  • The=20 assigned numbers for the SIP PBX already need to be communicated via ot= her=20 means oout of scope of the draft=20
  • There are other technical issues/considerations that would be= =20 resolved/considered if it was included, as articulated in Hadriel's sum= mary=20 slide package of the draft
     Making mandatory would raise = a large=20 number of questions and considerations, and the potential for implementin= g=20 something in the network that would never be used by recipiants. It = would=20 seem prudent to simply remove from the draft altogether at this=20 point.
 
    Thanks
       =20 Brian
--_000_EDC0A1AE77C57744B664A310A0B23AE209DCD4DCFRMRSSXCHMBSC3d_-- From D.Hancock@CableLabs.com Fri Jan 8 16:27:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A098C3A67CF for ; Fri, 8 Jan 2010 16:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6d982u949yw for ; Fri, 8 Jan 2010 16:27:21 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 5D2263A6407 for ; Fri, 8 Jan 2010 16:27:21 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id o090RIru017508; Fri, 8 Jan 2010 17:27:18 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Fri, 8 Jan 2010 17:27:18 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jan 2010 17:27:18 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60278F54D@srvxchg3.cablelabs.com> In-Reply-To: <4B47C443.6060702@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqQvRKtfDJkz6YQRd+8x+nFjGn+4gAAURiA References: <4B47C443.6060702@nostrum.com> From: "David Hancock" To: "Adam Roach" , "DRAGE, Keith (Keith)" X-Approved: ondar Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:27:22 -0000 Adam, Just to clarify, you're saying Flow-1 is bad, because it creates a routing loop. (The following flows assume the IP-PBX has used implicit registration to bind the enterprise AORs to a single IP-PBX contact address.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Flow-1 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Some network SP Network IP-PBX ------------ ---------- ------ [1]INVITE sip:usr1@sp.com --> [2]INVITE sip:usr1@sp.com --> Route: sip: [3]<-- INVITE sip:usr1@sp.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D To avoid the routing loop, the SP network must retarget the Request-URI of [2] so it contains the domain of the IP-PBX, as shown in Flow-2. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Flow-2 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Some network SP Network IP-PBX ------------ ---------- ------ [1]INVITE sip:usr1@sp.com --> [2]INVITE sip:usr1@pbx1.sp.com --> Route: sip: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My understanding is that Keith's text "...the Request-URI should not be replaced by the SSP on requests sent to the PBX" wasn't referring to Flow-2, but to Flow-3, where the SP terminating home proxy retargets the request to the registered contact address as shown in Flow-3.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Flow-3 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Some network SP Network IP-PBX ------------ ---------- ------ [1]INVITE sip:usr1@sp.com --> [2]INVITE sip: --> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My understanding is that Keith is saying that the message routing procedure in Flow-2 should apply for both "subscription" and "peering" modes (is that correct Keith?).=20 I hope this clarifies and doesn't confuse the issue. Thanks David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf > Of Adam Roach > Sent: Friday, January 08, 2010 4:48 PM > To: DRAGE, Keith (Keith) > Cc: martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/8/10 5:38 PM, DRAGE, Keith (Keith) wrote: > > I would like to see a SHOULD on something like: > > > > The mechansism should allow handling of inbound requests and outbound > requests between SSP and PBX to be as common as possible as for a normal > peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned. > The handing of requests at the incoming / outgoing gateway in the edge PBX > should be common once the mechanism has been applied. > > > > Essentially this means that the Request-URI should not be replaced by > the SSP on requests sent to the PBX. > > >=20 > No, I don't think this is correct. >=20 > Fundamentally, this is a 3261 registrar relationship (regardless of > whether we use NOTIFY or REGISTER), not a 3263 relationship. In > particular, what you propose cannot co-exist with the requirement: >=20 > - The mechanism MUST provide a means of avoiding problems dueto one side > using the mechanism and the other side not. >=20 >=20 > Because a failure to rewrite the URI means that the URI will still > resolve to the SSP under 3263 rules (since that's how it got there in > the first place). So, if it sends it to the PBX, and the PBX doesn't use > the MARTINI mechanism, it will apply 3263, and route it back to the SSP. > The SSP will then apply MARTINI rules and route it to the registered > PBX. Who will route it to the SSP. Which will then route it to the PBX. >=20 > And so on. >=20 > In particular, I think what you're describing is a requirement, but it > should be "MUST NOT", instead of SHOULD." >=20 > /a > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Jan 8 16:38:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10F7C3A6812 for ; Fri, 8 Jan 2010 16:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.33 X-Spam-Level: X-Spam-Status: No, score=-10.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNsFgfI1avkM for ; Fri, 8 Jan 2010 16:38:41 -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 BA8263A67FA for ; Fri, 8 Jan 2010 16:38:40 -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: ApoEALZeR0utJV2Z/2dsb2JhbADBSYkOB4pyhC8E X-IronPort-AV: E=Sophos;i="4.49,245,1262563200"; d="scan'208";a="79168596" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2010 00:38:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o090ccxX003503; Sat, 9 Jan 2010 00:38:38 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 18:38:37 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 18:38:37 -0600 Message-ID: <4B47D00C.9040208@cisco.com> Date: Fri, 08 Jan 2010 19:38:36 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2010 00:38:37.0579 (UTC) FILETIME=[151E7DB0:01CA90C4] Cc: David Hancock , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:38:42 -0000 DRAGE, Keith (Keith) wrote: > At the moment, from the IMS perspective, both mechanisms are there and > can be used FOR THE APPROPRIATE PURPOSE. From the IMS perspective, the > only mechanism which will tell you which URIs are currently registered > is reg-event. > > Because IMS always works in association with authentication, if URIs are > deregistered, then other things are going to stop working as well, so > for example outgoing requests from a deregistered URI may well not work. > Also note that because the implicit registration set is a whole, it is > unlikely individual URIs from the implicit registration set will > disappear. You will either lose them all or none of them. Because of > this I can envisage that a perfectly workable solution uses neither of > these mechanisms. That makes sense for phones. But I can imagine it wouldn't work so well for PBXes. E.g. suppose I requested that some of my lines be removed. (I had a layoff and don't need and can't afford them any longer.) At some point in time that request will take effect. Those lines should no longer be available to my PBX. That should be reflected as an indication that those particular lines are no longer registered. > Note that IMS does intend that certain reg event values do cause the UA > to recognise a failure and initiate a reregistration. In the absence of > this, the interconnect will be broken in both directions, because the > IMS has taken away its support for those URIs at that point. With a PBX it is much more important that there be no break in service than is the case with a single phone. There is a good chance there will be no time when the reregistration can be done without tearing down somebody's call. (If you insist on that "no calls unless registered" requirement.) Thanks, Paul > How many registrars outside IMS support reg event? Is it common? > > I would note also that none of John's current list of requirements needs > such a mechanism at all. So if people see the need for any such > mechanism to be mandated, they need to start exploring what the > requirements would be. > > regards > > Keith > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] > *On Behalf Of *Brian Lindsay > *Sent:* Friday, January 08, 2010 6:24 PM > *To:* Hadriel Kaplan; Elwell, John; David Hancock > *Cc:* martini@ietf.org > *Subject:* [martini] martini-shaken-implicit-registrations : propose > P-Associated-URI be removed > > Hi Hadriel / John / David, > > Regarding the martini-shaken-implicit-registrations draft, > currently the draft has the following requirement regarding support > of P-Associated-URI: > > The Registrar SHOULD indicate all of the implicitly Registered > AoRs in a P-Associated-URI header field(s) in the 200 response to > the REGISTER, if it supports [RFC3455]. [OPEN ISSUE: should we > mandate PAU support? Should we document a legal/compliant means of > indicating AoR username "wildcards"?] > As worded, this is a conditional SHOULD requirement (conditional > on whether RFC 3455 is supported by the Registrar), but there is a > question about whether PAU should be mandated. > > My suggestion would be to remove this requirement altogether: > > * PAU is not widely utilized outside of IMS and hence is likely > not part of most currently deployed SIP PBX > registration-based solutions today > * There haven't been any proposed requirements tabled to date > that would drive inclusion of this > * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), > there was a suggestion of making this optional, but I believe > none of the enterprise vendors ever saw any strong value case > for doing anything with the header, hence it was promptly > removed and never re-surfaced as a requirement in subsequent > drafts of the spec > * There are diffferences between RFC 3455 definitions of PAU and > IMS usage of the header that would need to be resolved in the > draft > * The assigned numbers for the SIP PBX already need to be > communicated via other means oout of scope of the draft > * There are other technical issues/considerations that would be > resolved/considered if it was included, as articulated in > Hadriel's summary slide package of the draft > > Making mandatory would raise a large number of questions and > considerations, and the potential for implementing something in the > network that would never be used by recipiants. It would seem > prudent to simply remove from the draft altogether at this point. > > Thanks > Brian > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Jan 8 16:48:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68753A68C5 for ; Fri, 8 Jan 2010 16:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW4vrhiyF7KC for ; Fri, 8 Jan 2010 16:48:31 -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 8D8D23A6890 for ; Fri, 8 Jan 2010 16:48:31 -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: ApoEAA9hR0utJV2b/2dsb2JhbADBQpQFhC8E X-IronPort-AV: E=Sophos;i="4.49,245,1262563200"; d="scan'208";a="79169314" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2010 00:48:29 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o090mSwQ008280; Sat, 9 Jan 2010 00:48:28 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 18:48:28 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Jan 2010 18:48:28 -0600 Message-ID: <4B47D25C.7030208@cisco.com> Date: Fri, 08 Jan 2010 19:48:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jan 2010 00:48:28.0430 (UTC) FILETIME=[754B32E0:01CA90C5] Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 00:48:32 -0000 DRAGE, Keith (Keith) wrote: > With regard to the intermediate proxies requirement, can we limit this to intermediate proxies in the SSP. > > For the PBX side, I have always considered an such mechanism as local to the gateway provided by the PBX, and not extending any further into the enterprise. If this applies, then it excludes any proxies on the PBX side of the gateway. Seems to me that argument also works (or actual also *doesn't* work) in reverse: the "proxies" on the SSP side could be considered as a local mechanism to the registrar provided by the SSP. If you look at it from the SSP side then you want your side to have the special treatment but are willing to sweep the issues of the other side under the rug. Same goes the other way. The fact is that its quite possible that the architecture is: pbx --- enterprise_sbc --- SP_sbc --- SP_other_stuff And the enterprise_sbc may be sourced independently of the pbx. (Though of course we would be happy to sell you both.) Thanks, Paul > regards > > Keith > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Friday, January 08, 2010 5:59 PM >> To: john.elwell@siemens-enterprise.com >> Cc: martini@ietf.org >> Subject: Re: [martini] Requirements - rev1 >> >> You have included a requirement that the mechanism MUST work >> in the presence of intermediate "proxies" between the PBX and >> the SSP's. Don't we need as well a requirement about the >> presence of intermediate enterprise proxies between the PBX >> and the SIP terminals, especially when considering inbound requests? >> >>> -----Message d'origine----- >>> De : martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] De la part de Elwell, >> John Envoyé : >>> vendredi 8 janvier 2010 18:46 À : martini@ietf.org Objet : >> [martini] >>> Requirements - rev1 >>> >>> Revised following the feedback since yesterday. Please continue the >>> feedback. >>> >>> - The mechanism MUST allow the PBX to be responsible for >> its AORs and >>> to handle requests to those AORs according to its rules. >>> - The mechanism MUST allow the PBX to receive requests to its AORs >>> that originate off-PBX and arrive via the SSP, so that the PBX can >>> handle those requests according to its rules. >>> - The mechanism MUST provide a means whereby the PBX knows which of >>> its AORs an inbound request is targeted at. >>> - The mechanism MUST provide a means of avoiding problems >> due to one >>> side using the mechanism and the other side not. >>> - The mechanism MUST observe SIP backwards compatibility principles. >>> - The mechanism MUST work in the presence of intermediate "proxies" >>> between the PBX and the SSP's domain proxy, where those >> intermediate >>> "proxies" need to be on the path of inbound requests to the PBX. >>> - The mechanism MUST work when the PBX obtains its IP address >>> dynamically. >>> - The mechanism MUST work without requiring the PBX to publish >>> reachability information through the DNS. >>> >>> Also some desiderata: >>> - The mechanism SHOULD allow SSPs to exploit its mechanisms for >>> providing SIP service to ordinary subscribers in order to provide a >>> SIP trunking service to PBXs. >>> - The mechanism SHOULD scale to PBXs of several thousand AORs. >>> - The mechanism SHOULD require relatively modest changes to a >>> substantial population of existing SSP and PBX implementations, in >>> order to encourage a fast market adoption of the standardized >>> mechanism. >>> >>> John >>> >>> >>> >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> >> ********************************* >> This message and any attachments (the "message") are >> confidential and intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if >> altered, changed or falsified. >> If you are not the intended addressee of this message, please >> cancel it immediately and inform the sender. >> ******************************** >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From drage@alcatel-lucent.com Fri Jan 8 17:00:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858F13A67FA for ; Fri, 8 Jan 2010 17:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=-0.941, 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 5c6Evb9kqWiT for ; Fri, 8 Jan 2010 17:00:50 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 53ABE3A67D4 for ; Fri, 8 Jan 2010 17:00:49 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0910imw014283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 02:00:44 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 9 Jan 2010 02:00:44 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Sat, 9 Jan 2010 02:00:42 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqQxXjHpnD4Ww/qReiC+35MiUcwlAAAWAOQ Message-ID: References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> <4B47D25C.7030208@cisco.com> In-Reply-To: <4B47D25C.7030208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 01:00:51 -0000 Yes, but in that case why doesn't the enterprise SBC support the PBX end of= "the mechanism", rather than the PBX itself. Remember that the PBX network as a whole does not need to know about "the m= echanism". It is purely local to the interface. Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Saturday, January 09, 2010 12:48 AM > To: DRAGE, Keith (Keith) > Cc: bruno.chatras@orange-ftgroup.com;=20 > john.elwell@siemens-enterprise.com; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > With regard to the intermediate proxies requirement, can we=20 > limit this to intermediate proxies in the SSP. > >=20 > > For the PBX side, I have always considered an such=20 > mechanism as local to the gateway provided by the PBX, and=20 > not extending any further into the enterprise. If this=20 > applies, then it excludes any proxies on the PBX side of the gateway. >=20 > Seems to me that argument also works (or actual also=20 > *doesn't* work) in > reverse: the "proxies" on the SSP side could be considered as=20 > a local mechanism to the registrar provided by the SSP. >=20 > If you look at it from the SSP side then you want your side=20 > to have the special treatment but are willing to sweep the=20 > issues of the other side under the rug. Same goes the other way. >=20 > The fact is that its quite possible that the architecture is: >=20 > pbx --- enterprise_sbc --- SP_sbc --- SP_other_stuff >=20 > And the enterprise_sbc may be sourced independently of the pbx. > (Though of course we would be happy to sell you both.) >=20 > Thanks, > Paul >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of=20 > >> bruno.chatras@orange-ftgroup.com > >> Sent: Friday, January 08, 2010 5:59 PM > >> To: john.elwell@siemens-enterprise.com > >> Cc: martini@ietf.org > >> Subject: Re: [martini] Requirements - rev1 > >> > >> You have included a requirement that the mechanism MUST=20 > work in the=20 > >> presence of intermediate "proxies" between the PBX and the SSP's.=20 > >> Don't we need as well a requirement about the presence of=20 > >> intermediate enterprise proxies between the PBX and the SIP=20 > >> terminals, especially when considering inbound requests? > >> > >>> -----Message d'origine----- > >>> De : martini-bounces@ietf.org > >>> [mailto:martini-bounces@ietf.org] De la part de Elwell, > >> John Envoy=E9 :=20 > >>> vendredi 8 janvier 2010 18:46 =C0 : martini@ietf.org Objet :=20 > >> [martini] > >>> Requirements - rev1 > >>> > >>> Revised following the feedback since yesterday. Please=20 > continue the=20 > >>> feedback. > >>> > >>> - The mechanism MUST allow the PBX to be responsible for > >> its AORs and > >>> to handle requests to those AORs according to its rules. > >>> - The mechanism MUST allow the PBX to receive requests to=20 > its AORs=20 > >>> that originate off-PBX and arrive via the SSP, so that=20 > the PBX can=20 > >>> handle those requests according to its rules. > >>> - The mechanism MUST provide a means whereby the PBX=20 > knows which of=20 > >>> its AORs an inbound request is targeted at. > >>> - The mechanism MUST provide a means of avoiding problems > >> due to one > >>> side using the mechanism and the other side not. > >>> - The mechanism MUST observe SIP backwards compatibility=20 > principles. > >>> - The mechanism MUST work in the presence of intermediate=20 > "proxies"=20 > >>> between the PBX and the SSP's domain proxy, where those > >> intermediate > >>> "proxies" need to be on the path of inbound requests to the PBX. > >>> - The mechanism MUST work when the PBX obtains its IP address=20 > >>> dynamically. > >>> - The mechanism MUST work without requiring the PBX to publish=20 > >>> reachability information through the DNS. > >>> > >>> Also some desiderata: > >>> - The mechanism SHOULD allow SSPs to exploit its mechanisms for=20 > >>> providing SIP service to ordinary subscribers in order to=20 > provide a=20 > >>> SIP trunking service to PBXs. > >>> - The mechanism SHOULD scale to PBXs of several thousand AORs. > >>> - The mechanism SHOULD require relatively modest changes to a=20 > >>> substantial population of existing SSP and PBX=20 > implementations, in=20 > >>> order to encourage a fast market adoption of the standardized=20 > >>> mechanism. > >>> > >>> John > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> martini mailing list > >>> martini@ietf.org > >>> https://www.ietf.org/mailman/listinfo/martini > >>> > >> ********************************* > >> This message and any attachments (the "message") are=20 > confidential and=20 > >> intended solely for the addressees. > >> Any unauthorised use or dissemination is prohibited. > >> Messages are susceptible to alteration.=20 > >> France Telecom Group shall not be liable for the message=20 > if altered,=20 > >> changed or falsified. > >> If you are not the intended addressee of this message,=20 > please cancel=20 > >> it immediately and inform the sender. > >> ******************************** > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > = From drage@alcatel-lucent.com Fri Jan 8 17:17:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EFF3A6767 for ; Fri, 8 Jan 2010 17:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.138 X-Spam-Level: X-Spam-Status: No, score=-5.138 tagged_above=-999 required=5 tests=[AWL=1.111, 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 0yo368Yo+7rR for ; Fri, 8 Jan 2010 17:17:35 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 92FA93A659C for ; Fri, 8 Jan 2010 17:17:34 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o091HRmF023432 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 9 Jan 2010 02:17:27 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 9 Jan 2010 02:17:27 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Adam Roach , Christer Holmberg Date: Sat, 9 Jan 2010 02:17:26 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP65KxO6rNEx8qRwS919b8/WYnvQAYQ3kQAB8b89A= Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2010 01:17:36 -0000 I don't think there is anything particularly IMS specific about what I was = saying.=20 I can take you back to ISDN days and point you at the work there as well. D= SS1 T reference point procedures assume that the functionality for dealing = with specific extensions is on the PBX side of the interface.=20 Put that functionality back on the public network side of the interface, an= d you have an access concentrator and Centrex, not a PBX. I don't see how a lot of that model (which is essentially a business relati= onship model at the start) changes with VOIP. regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, January 08, 2010 10:29 AM > To: Adam Roach; Christer Holmberg > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > I think Christer's summary is good. The architecture that=20 > Keith and others are talking about is applicable outside IMS=20 > too - that is what the SIP Forum is trying to achieve with=20 > SIPconnect - a means for a PBX to register. This was probably=20 > a lot clearer with the earlier domain registration draft=20 > ("stirred"), but it is still the same principle with the=20 > current implicit registration draft ("shaken"). >=20 > John >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 07 January 2010 22:49 > > To: Christer Holmberg > > Cc: martini@ietf.org; Hadriel Kaplan > > Subject: Re: [martini] draft-roach-martini-up-00 > >=20 > > You're spot on in describing the differences in perspectives.=20 > > I think it > > comes down to whether you see an application for SIP outside of IMS=20 > > architectures. > >=20 > > In IMS-derived architectures, you can make the assumptions=20 > Keith has.=20 > > In the general case, I don't think they hold. > >=20 > > /a > >=20 > > On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > > > Hi, > > > > > > I think one of the reason we go over the same thing over > > and over is because we don't have a common view on the=20 > "user" concept. > > > > > > Adam talks about multiple users, and that using a single > > REGISTER for those breaks things. Keith (and maybe others)=20 > seems to be=20 > > arguing that we are still talking about a SINGLE SIP user. What=20 > > happens inside the PBX is irrelevant. The PBX users have a relation=20 > > with the PBX - the PBX has a relation with the SIP network. > > > > > > So, from Keith's perspective things would not be broken, > > and intermediates in the SIP network do not (at least not by > > default) need to be aware of individual users behind the PBX. > > > > > > But, I may have missunderstood, and in that case I appologize :) > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > > Sent: 8. tammikuuta 2010 0:23 > > > To: Hadriel Kaplan > > > Cc: martini@ietf.org > > > Subject: Re: [martini] draft-roach-martini-up-00 > > > > > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > > > =20 > > >> I don't understand why you think using a REGISTER > > transaction makes it any more or less architecture-specific than a=20 > > PUBLISH one. > > >> > > >> =20 > > > That's not what I'm saying. There's been a lot of > > back-and-forth on this topic that amounts to the same exchange over=20 > > and over (not just with you; with several parties). I'm going to=20 > > replay the dialog in simplified form, because I think something is=20 > > getting lost with the flood of email > > > messages: > > > > > > A: "Changing REGISTER in this way can break intermediaries." > > > B: "But in the architecture MARTINI is considering, it > > breaks nothing." > > > A: "The fact that it works in one place does not mean it > > works everywhere." > > > > > > Changing the established meaning of REGISTER can cause > > problems unless all parties to the transaction understand=20 > the changes.=20 > > The fact that no such problem arises in one specific architecture=20 > > seems to be held out as proof that it must work everywhere.=20 > Which is=20 > > the logical equivalent to: > > > "this particular swan is white, therefore all swans must be > > white." (cf > > >=20 > > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori > > cal_inference) > > > > > > What I'm proposing with PUBLISH isn't a change to > > established semantics. > > > In fact, it aligns precisely with established semantics: as > > I said on the phone, the basic concept of using PUBLISH to update a=20 > > Location Service database could be a BCP, since it requires no new=20 > > protocol mechanism. Nothing breaks, since the meaning of everything=20 > > remains the same. > > > > > > Everything else I've proposed so far is properly negotiated > > SIP protocol extensions using established extension mechanisms. You=20 > > could do the same thing with REGISTER, if you really wanted to, by=20 > > using both Require and Proxy-Require. > > > > > > /a > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > =20 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bruno.chatras@orange-ftgroup.com Mon Jan 11 00:20:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 121E63A69EE for ; Mon, 11 Jan 2010 00:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 I0Bern8ZY1eH for ; Mon, 11 Jan 2010 00:20:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id CB13C3A69E9 for ; Mon, 11 Jan 2010 00:20:09 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7BC44190250; Mon, 11 Jan 2010 09:20:06 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 54391158052; Mon, 11 Jan 2010 09:20:03 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:20:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jan 2010 09:20:01 +0100 Message-ID: <13382_1263198003_4B4ADF33_13382_65828_1_9ECCF01B52E7AB408A7EB85352642141ED0030@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQA1fbcwAAwt5KAAdnriwA== References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 11 Jan 2010 08:20:03.0228 (UTC) FILETIME=[DFE0C5C0:01CA9296] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.11.75139 Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 08:20:11 -0000 I was alluding to this requirement as one of the reasons why the R-URI shou= ld not be replaced by the contact address (at least if we want to keep the = gateway function as simple as possible). > -----Message d'origine----- > De : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Envoy=E9 : samedi 9 janvier 2010 00:46 > =C0 : CHATRAS Bruno RD-CORE-ISS; john.elwell@siemens-enterprise.com > Cc : martini@ietf.org > Objet : RE: [martini] Requirements - rev1 >=20 > With regard to the intermediate proxies requirement, can we=20 > limit this to intermediate proxies in the SSP. >=20 > For the PBX side, I have always considered an such mechanism=20 > as local to the gateway provided by the PBX, and not=20 > extending any further into the enterprise. If this applies,=20 > then it excludes any proxies on the PBX side of the gateway. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > > bruno.chatras@orange-ftgroup.com > > Sent: Friday, January 08, 2010 5:59 PM > > To: john.elwell@siemens-enterprise.com > > Cc: martini@ietf.org > > Subject: Re: [martini] Requirements - rev1 > >=20 > > You have included a requirement that the mechanism MUST work in the=20 > > presence of intermediate "proxies" between the PBX and the SSP's.=20 > > Don't we need as well a requirement about the presence of=20 > intermediate=20 > > enterprise proxies between the PBX and the SIP terminals,=20 > especially=20 > > when considering inbound requests? > >=20 > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell, > > John Envoy=E9 :=20 > > > vendredi 8 janvier 2010 18:46 =C0 : martini@ietf.org Objet :=20 > > [martini] > > > Requirements - rev1 > > >=20 > > > Revised following the feedback since yesterday. Please=20 > continue the=20 > > > feedback. > > >=20 > > > - The mechanism MUST allow the PBX to be responsible for > > its AORs and > > > to handle requests to those AORs according to its rules. > > > - The mechanism MUST allow the PBX to receive requests to=20 > its AORs=20 > > > that originate off-PBX and arrive via the SSP, so that=20 > the PBX can=20 > > > handle those requests according to its rules. > > > - The mechanism MUST provide a means whereby the PBX=20 > knows which of=20 > > > its AORs an inbound request is targeted at. > > > - The mechanism MUST provide a means of avoiding problems > > due to one > > > side using the mechanism and the other side not. > > > - The mechanism MUST observe SIP backwards compatibility=20 > principles. > > > - The mechanism MUST work in the presence of intermediate=20 > "proxies"=20 > > > between the PBX and the SSP's domain proxy, where those > > intermediate > > > "proxies" need to be on the path of inbound requests to the PBX. > > > - The mechanism MUST work when the PBX obtains its IP address=20 > > > dynamically. > > > - The mechanism MUST work without requiring the PBX to publish=20 > > > reachability information through the DNS. > > >=20 > > > Also some desiderata: > > > - The mechanism SHOULD allow SSPs to exploit its mechanisms for=20 > > > providing SIP service to ordinary subscribers in order to=20 > provide a=20 > > > SIP trunking service to PBXs. > > > - The mechanism SHOULD scale to PBXs of several thousand AORs. > > > - The mechanism SHOULD require relatively modest changes to a=20 > > > substantial population of existing SSP and PBX=20 > implementations, in=20 > > > order to encourage a fast market adoption of the standardized=20 > > > mechanism. > > >=20 > > > John > > >=20 > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > >=20 > > ********************************* > > This message and any attachments (the "message") are=20 > confidential and=20 > > intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration.=20 > > France Telecom Group shall not be liable for the message if=20 > altered,=20 > > changed or falsified. > > If you are not the intended addressee of this message,=20 > please cancel=20 > > it immediately and inform the sender. > > ******************************** > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Mon Jan 11 00:30:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB8C3A69EA for ; Mon, 11 Jan 2010 00:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 DjGSUIRJ7kiX for ; Mon, 11 Jan 2010 00:30:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 208F93A69D7 for ; Mon, 11 Jan 2010 00:30:05 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 42523190320; Mon, 11 Jan 2010 09:30:02 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1DE72158060; Mon, 11 Jan 2010 09:30:02 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:30: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: Mon, 11 Jan 2010 09:30:00 +0100 Message-ID: <13382_1263198602_4B4AE18A_13382_66566_1_9ECCF01B52E7AB408A7EB85352642141ED0049@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <014001ca90a1$51e99f40$f5bcddc0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] martini-shaken-implicit-registrations: propose P-Associated-URI be removed Thread-Index: AcqQknZtVtrOG1JyRm+dwfjhVBgdygAARVAQAANwHDAAfW9bsA== References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> <4B477CCE.5080906@cisco.com> <014001ca90a1$51e99f40$f5bcddc0$@us> From: To: , X-OriginalArrivalTime: 11 Jan 2010 08:30:01.0941 (UTC) FILETIME=[44BD2050:01CA9298] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.11.75139 Subject: Re: [martini] martini-shaken-implicit-registrations: propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 08:30:06 -0000 I accept that the PBX may not need the P-Associated-URI. However I believe = that sending the PAU by the registrar is required in architectures where th= e edge proxy is the entity responsible for asserting calling party identiti= es (i.e. P-Preferred-Identity to P-Asserted-Identity conversion).=20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Richard Shockey > Envoy=E9 : vendredi 8 janvier 2010 21:30 > =C0 : martini@ietf.org > Objet : Re: [martini] martini-shaken-implicit-registrations:=20 > propose P-Associated-URI be removed >=20 > +1 >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20=20 > > Behalf Of Bernard Aboba > > Sent: Friday, January 08, 2010 1:51 PM > > To: 'Paul Kyzivat'; 'Brian Lindsay' > > Cc: 'Hadriel Kaplan'; 'David Hancock'; martini@ietf.org > > Subject: Re: [martini] martini-shaken-implicit-registrations :=20 > > propose P-Associated-URI be removed > >=20=20 > > +1. > >=20=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, January 08, 2010 10:43 AM > > To: Brian Lindsay > > Cc: David Hancock; Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] martini-shaken-implicit-registrations :=20 > > propose P-Associated-URI be removed > >=20=20 > > I agree. This info can be learned more reliably using the=20 > reg event=20=20 > > package. The PBX is probably going to want that anyway. > >=20=20 > > Thanks, > > Paul > >=20=20 > > Brian Lindsay wrote: > > > Hi Hadriel / John / David, > > > > > > Regarding the martini-shaken-implicit-registrations draft, > > currently > > > the draft has the following requirement regarding support of >=20 > > P-Associated-URI: > > > > > > The Registrar SHOULD indicate all of the implicitly Registered=20 > > AoRs in > a P-Associated-URI header field(s) in the 200=20 > response to=20 > > the REGISTER, > if it supports [RFC3455]. [OPEN ISSUE: should we=20 > > mandate PAU support? > > > Should we document a legal/compliant means of indicating AoR=20=20 > > username > "wildcards"?] > > > As worded, this is a conditional SHOULD requirement=20 > (conditional > > on > > > whether RFC 3455 is supported by the Registrar), but there is a=20= =20 > > question > about whether PAU should be mandated. > > > > > > My suggestion would be to remove this requirement altogether: > > > > > > * PAU is not widely utilized outside of IMS and=20 > hence is likely > > not > > > part of most currently deployed SIP PBX > > > registration-based solutions today > > > * There haven't been any proposed requirements tabled to date > > that > > > would drive inclusion of this > > > * In a very early draft of SIP Connect 1.1 ( > 1.5=20 > years ago), > > there > > > was a suggestion of making this optional, but I=20 > believe none > > of > > > the enterprise vendors ever saw any strong value case for > > doing > > > anything with the header, hence it was promptly removed and > > never > > > re-surfaced as a requirement in subsequent drafts=20 > of the spec > > > * There are diffferences between RFC 3455=20 > definitions of PAU and > > IMS > > > usage of the header that would need to be resolved in the > > draft > > > * The assigned numbers for the SIP PBX already need to be > > > communicated via other means oout of scope of the draft > > > * There are other technical issues/considerations=20 > that would be > > > resolved/considered if it was included, as articulated in > > > Hadriel's summary slide package of the draft > > > > > > Making mandatory would raise a large number of questions and > > > considerations, and the potential for implementing=20 > something in the=20=20 > > > network that would never be used by recipiants. It would seem=20=20 > > prudent to > simply remove from the draft altogether at this point. > > > > > > Thanks > > > Brian > > > > > > > > >=20 > > -------------------------------------------------------------------- > > ---- > > > > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > >=20=20 > >=20=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Mon Jan 11 00:47:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAACD3A67BE for ; Mon, 11 Jan 2010 00:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 RAotnmbUuwHr for ; Mon, 11 Jan 2010 00:47:30 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B6C1F3A6908 for ; Mon, 11 Jan 2010 00:47:29 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-489342; Mon, 11 Jan 2010 09:47:26 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2322B23F0278; Mon, 11 Jan 2010 09:47:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 11 Jan 2010 09:47:26 +0100 From: "Elwell, John" To: Paul Kyzivat , Brian Lindsay Date: Mon, 11 Jan 2010 09:47:24 +0100 Thread-Topic: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed Thread-Index: AcqQknqvL42Gtv0aRiaUrozokJWFvQCCDGpg Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> <4B477CCE.5080906@cisco.com> In-Reply-To: <4B477CCE.5080906@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: David Hancock , Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 08:47:31 -0000 I agree. John=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 08 January 2010 18:43 > To: Brian Lindsay > Cc: Hadriel Kaplan; Elwell, John; David Hancock; martini@ietf.org > Subject: Re: [martini] martini-shaken-implicit-registrations=20 > : propose P-Associated-URI be removed >=20 > I agree. This info can be learned more reliably using the reg event=20 > package. The PBX is probably going to want that anyway. >=20 > Thanks, > Paul >=20 > Brian Lindsay wrote: > > Hi Hadriel / John / David, > > =20 > > Regarding the martini-shaken-implicit-registrations=20 > draft, currently=20 > > the draft has the following requirement regarding support of=20 > > P-Associated-URI: > > =20 > > The Registrar SHOULD indicate all of the implicitly=20 > Registered AoRs in=20 > > a P-Associated-URI header field(s) in the 200 response to=20 > the REGISTER,=20 > > if it supports [RFC3455]. [OPEN ISSUE: should we mandate=20 > PAU support? =20 > > Should we document a legal/compliant means of indicating=20 > AoR username=20 > > "wildcards"?] > > As worded, this is a conditional SHOULD requirement=20 > (conditional on=20 > > whether RFC 3455 is supported by the Registrar), but there=20 > is a question=20 > > about whether PAU should be mandated. > > =20 > > My suggestion would be to remove this requirement altogether: > >=20 > > * PAU is not widely utilized outside of IMS and hence=20 > is likely not > > part of most currently deployed SIP PBX > > registration-based solutions today > > * There haven't been any proposed requirements tabled=20 > to date that > > would drive inclusion of this > > * In a very early draft of SIP Connect 1.1 ( > 1.5=20 > years ago), there > > was a suggestion of making this optional, but I=20 > believe none of > > the enterprise vendors ever saw any strong value case=20 > for doing > > anything with the header, hence it was promptly=20 > removed and never > > re-surfaced as a requirement in subsequent drafts of the spec > > * There are diffferences between RFC 3455 definitions=20 > of PAU and IMS > > usage of the header that would need to be resolved in=20 > the draft > > * The assigned numbers for the SIP PBX already need to be > > communicated via other means oout of scope of the draft > > * There are other technical issues/considerations that would be > > resolved/considered if it was included, as articulated in > > Hadriel's summary slide package of the draft > >=20 > > Making mandatory would raise a large number of questions and=20 > > considerations, and the potential for implementing something in the=20 > > network that would never be used by recipiants. It would=20 > seem prudent to=20 > > simply remove from the draft altogether at this point. > > =20 > > Thanks > > Brian > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Mon Jan 11 01:13:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BA63A6924 for ; Mon, 11 Jan 2010 01:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 AOonerl37GN2 for ; Mon, 11 Jan 2010 01:13:48 -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 F15723A6903 for ; Mon, 11 Jan 2010 01:13:47 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-489896; Mon, 11 Jan 2010 10:13:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 3FB851EB8293; Mon, 11 Jan 2010 10:13:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 11 Jan 2010 10:13:44 +0100 From: "Elwell, John" To: Adam Roach , "DRAGE, Keith (Keith)" Date: Mon, 11 Jan 2010 10:13:43 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqQvRHT0mR0K5hIRIuVVnV0DdJaxQB35DNw Message-ID: References: <4B47C443.6060702@nostrum.com> In-Reply-To: <4B47C443.6060702@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:13:49 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 08 January 2010 23:48 > To: DRAGE, Keith (Keith) > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/8/10 5:38 PM, DRAGE, Keith (Keith) wrote: > > I would like to see a SHOULD on something like: > > > > The mechansism should allow handling of inbound requests=20 > and outbound requests between SSP and PBX to be as common as=20 > possible as for a normal peering arrangement (e.g. RFC 3263=20 > based), as far as the PBX is concerned. The handing of=20 > requests at the incoming / outgoing gateway in the edge PBX=20 > should be common once the mechanism has been applied. > > > > Essentially this means that the Request-URI should not be=20 > replaced by the SSP on requests sent to the PBX. > > =20 >=20 > No, I don't think this is correct. >=20 > Fundamentally, this is a 3261 registrar relationship (regardless of=20 > whether we use NOTIFY or REGISTER), not a 3263 relationship. In=20 > particular, what you propose cannot co-exist with the requirement: >=20 > - The mechanism MUST provide a means of avoiding problems=20 > dueto one side using the mechanism and the other side not. >=20 >=20 > Because a failure to rewrite the URI means that the URI will still=20 > resolve to the SSP under 3263 rules (since that's how it got there in=20 > the first place). So, if it sends it to the PBX, and the PBX=20 > doesn't use=20 > the MARTINI mechanism, it will apply 3263, and route it back=20 > to the SSP.=20 > The SSP will then apply MARTINI rules and route it to the registered=20 > PBX. Who will route it to the SSP. Which will then route it=20 > to the PBX. [JRE] I agree with Adam, in that the Request-URI received by the PBX must b= e an AOR as recognised by the PBX, to avoid looping. For example, if the or= iginal Request-URI (as received by the SSP from the UAC) is sip:+12345@ssp.= net or tel:+12345, then it should be replaced by something like sip:+12345@= enterprise.com. The point is, the Request-URI still identifies the target A= OR, and is not simply the single contact URI that was registered. So although it would seem reasonable to add a requirement along the lines t= hat Keith suggested, I would be inclined to suppress the bit "Essentially t= his means..." as going beyond requirements. John >=20 > And so on. >=20 > In particular, I think what you're describing is a=20 > requirement, but it=20 > should be "MUST NOT", instead of SHOULD." >=20 > /a > = From christer.holmberg@ericsson.com Mon Jan 11 01:15:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA2A3A69EA for ; Mon, 11 Jan 2010 01:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[AWL=0.353, 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 BB0UxAuX5VYn for ; Mon, 11 Jan 2010 01:15:16 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6032D3A6974 for ; Mon, 11 Jan 2010 01:15:16 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-94-4b4aec20d41c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 43.53.04178.02CEA4B4; Mon, 11 Jan 2010 10:15:12 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 11 Jan 2010 10:15:12 +0100 From: Christer Holmberg To: Paul Kyzivat , Adam Roach Date: Mon, 11 Jan 2010 10:15:10 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqQqEjBU5bc8BKpQPKHeJqsESeXMAB9fitQ Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> <4B474C3F.7090601@nostrum.com> <4B47A15C.4050708@cisco.com> In-Reply-To: <4B47A15C.4050708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Alan Johnston , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:15:17 -0000 Hi,=20 >>>My point was that an intermediary "proxy" should not try to infer any=20 >>>semantics from a REGISTER - not that one can not imagine an >>>architecture where this could break things. The=20 >>>REGISTER method is between the UA and the Registrar, and I don't recall = anything in=20 >>>Section 16 of RFC 3261 behavior (which defines a SIP proxy) that is=20 >>>REGISTER specific. >>> >>>If this "proxy" is trying to infer semantics from a REGISTER, then it=20 >>>is effectively no longer a proxy (per RFC 3261) but instead is acting=20 >>>a Registrar. If so, then, it must understand the option tag in order=20 >>>to infer correct semantics from the REGISTER. >>=20 >>Ideally, this would all be true. In practice, with the introduction of=20 >>the Service-Route and Path mechanisms, we have invited proxies into=20 >>the REGISTER transaction. And, for better or for worse, those=20 >>particular cats are both well out of the bag and marking the furniture. >=20 >Yes. IMS is the poster child here. The P-CSCF and I-CSCF are=20 >heavily coupled to REGISTER. They typically are B2BUAs rather=20 >than proxies I think, but they try to pretend to be proxy-like. >=20 >In any case, everybody and his brother seem to think that=20 >intermediate devices should be able to make decisions about=20 >who can and can't receive traffic based on whether they are=20 >registered or not. IMO that is a terrible concept, but still=20 >it is there. IF the PBX is seen as a single user from the SIP network perspective, I don= 't think "proxies" will make decisssion on which PBX users will be allowed = to receive traffic or not. Intermediates have no knowledge of those. Regards, Christer= From christer.holmberg@ericsson.com Mon Jan 11 01:16:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EE23A6974 for ; Mon, 11 Jan 2010 01:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.282, 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 pQ2EFCI9ZBgI for ; Mon, 11 Jan 2010 01:16:52 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A2C603A69E6 for ; Mon, 11 Jan 2010 01:16:51 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-70-4b4aec7f9d6d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id AF.C3.04178.F7CEA4B4; Mon, 11 Jan 2010 10:16:48 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 11 Jan 2010 10:16:47 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Mon, 11 Jan 2010 10:16:47 +0100 From: Christer Holmberg To: Paul Kyzivat , "Elwell, John" Date: Mon, 11 Jan 2010 10:16:46 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqQqImyROSZgTshT9CXjMChNJe90gB9hUoA Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> <4B47A193.4080805@cisco.com> In-Reply-To: <4B47A193.4080805@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 09:16:53 -0000 Hi,=20 >>I think Christer's summary is good. The architecture that=20 >>Keith and others are talking about is applicable outside IMS=20 >>too - that is what the SIP Forum is trying to achieve with=20 >>SIPconnect - a means for a PBX to register. This was probably=20 >>a lot clearer with the earlier domain registration draft=20 >>("stirred"), but it is still the same principle with the=20 >>current implicit registration draft ("shaken"). >=20 >Yes, it is certainly an approach that has popularity beyond IMS. I agree. I was going to mention SIPConnect in my initial e-mail, but I forg= ot. But, in that case, there is no need for the SIP network intermediates to ha= ve knowledge about individual PBX users, since the PBX is seen as a single = user. Regards, Christer > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > >> Sent: 07 January 2010 22:49 > >> To: Christer Holmberg > >> Cc: martini@ietf.org; Hadriel Kaplan > >> Subject: Re: [martini] draft-roach-martini-up-00 > >> > >> You're spot on in describing the differences in perspectives.=20 > >> I think it > >> comes down to whether you see an application for SIP=20 > outside of IMS=20 > >> architectures. > >> > >> In IMS-derived architectures, you can make the assumptions=20 > Keith has.=20 > >> In the general case, I don't think they hold. > >> > >> /a > >> > >> On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > >>> Hi, > >>> > >>> I think one of the reason we go over the same thing over > >> and over is because we don't have a common view on the=20 > "user" concept. > >>> Adam talks about multiple users, and that using a single > >> REGISTER for those breaks things. Keith (and maybe others)=20 > seems to=20 > >> be arguing that we are still talking about a SINGLE SIP user. What=20 > >> happens inside the PBX is irrelevant. The PBX users have a=20 > relation=20 > >> with the PBX - the PBX has a relation with the SIP network. > >>> So, from Keith's perspective things would not be broken, > >> and intermediates in the SIP network do not (at least not by > >> default) need to be aware of individual users behind the PBX. > >>> But, I may have missunderstood, and in that case I appologize :) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > >>> Sent: 8. tammikuuta 2010 0:23 > >>> To: Hadriel Kaplan > >>> Cc: martini@ietf.org > >>> Subject: Re: [martini] draft-roach-martini-up-00 > >>> > >>> On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > >>> =20 > >>>> I don't understand why you think using a REGISTER > >> transaction makes it any more or less architecture-specific than a=20 > >> PUBLISH one. > >>>> =20 > >>> That's not what I'm saying. There's been a lot of > >> back-and-forth on this topic that amounts to the same=20 > exchange over=20 > >> and over (not just with you; with several parties). I'm going to=20 > >> replay the dialog in simplified form, because I think something is=20 > >> getting lost with the flood of email > >>> messages: > >>> > >>> A: "Changing REGISTER in this way can break intermediaries." > >>> B: "But in the architecture MARTINI is considering, it > >> breaks nothing." > >>> A: "The fact that it works in one place does not mean it > >> works everywhere." > >>> Changing the established meaning of REGISTER can cause > >> problems unless all parties to the transaction understand the=20 > >> changes. The fact that no such problem arises in one specific=20 > >> architecture seems to be held out as proof that it must work=20 > >> everywhere. Which is the logical equivalent to: > >>> "this particular swan is white, therefore all swans must be > >> white." (cf > >> http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori > >> cal_inference) > >>> What I'm proposing with PUBLISH isn't a change to > >> established semantics. > >>> In fact, it aligns precisely with established semantics: as > >> I said on the phone, the basic concept of using PUBLISH to=20 > update a=20 > >> Location Service database could be a BCP, since it requires no new=20 > >> protocol mechanism. Nothing breaks, since the meaning of=20 > everything=20 > >> remains the same. > >>> Everything else I've proposed so far is properly negotiated > >> SIP protocol extensions using established extension=20 > mechanisms. You=20 > >> could do the same thing with REGISTER, if you really wanted to, by=20 > >> using both Require and Proxy-Require. > >>> /a > >>> _______________________________________________ > >>> martini mailing list > >>> martini@ietf.org > >>> https://www.ietf.org/mailman/listinfo/martini > >>> =20 > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > = From john.elwell@siemens-enterprise.com Mon Jan 11 02:07:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF88D3A691E for ; Mon, 11 Jan 2010 02:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 BPQyIE0fJILP for ; Mon, 11 Jan 2010 02:07:23 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3AD873A68F7 for ; Mon, 11 Jan 2010 02:07:22 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-490863; Mon, 11 Jan 2010 11:07:19 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A52431EB8293; Mon, 11 Jan 2010 11:07:19 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 11 Jan 2010 11:07:19 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "richard@shockey.us" , "martini@ietf.org" Date: Mon, 11 Jan 2010 11:07:17 +0100 Thread-Topic: [martini] martini-shaken-implicit-registrations: propose P-Associated-URI be removed Thread-Index: AcqQknZtVtrOG1JyRm+dwfjhVBgdygAARVAQAANwHDAAfW9bsAADpn8g Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B474677.9090803@nostrum.com><4B474CC3.6080005@nostrum.com> <4B476121.5010708@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C057A49@zcarhxm1.corp.nortel.com> <4B477CCE.5080906@cisco.com> <014001ca90a1$51e99f40$f5bcddc0$@us> <13382_1263198602_4B4AE18A_13382_66566_1_9ECCF01B52E7AB408A7EB85352642141ED0049@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <13382_1263198602_4B4AE18A_13382_66566_1_9ECCF01B52E7AB408A7EB85352642141ED0049@ftrdmel0.rd.francetelecom.fr> 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: [martini] martini-shaken-implicit-registrations: propose P-Associated-URI be removed X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 10:07:24 -0000 Bruno, But this does not mean there is a requirement for the edge proxy to send it= to the PBX. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: 11 January 2010 08:30 > To: richard@shockey.us; martini@ietf.org > Subject: Re: [martini] martini-shaken-implicit-registrations:=20 > propose P-Associated-URI be removed >=20 > I accept that the PBX may not need the P-Associated-URI.=20 > However I believe that sending the PAU by the registrar is=20 > required in architectures where the edge proxy is the entity=20 > responsible for asserting calling party identities (i.e.=20 > P-Preferred-Identity to P-Asserted-Identity conversion).=20 >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Richard Shockey > > Envoy=E9 : vendredi 8 janvier 2010 21:30 > > =C0 : martini@ietf.org > > Objet : Re: [martini] martini-shaken-implicit-registrations:=20 > > propose P-Associated-URI be removed > >=20 > > +1 > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] On =20 > > > Behalf Of Bernard Aboba > > > Sent: Friday, January 08, 2010 1:51 PM > > > To: 'Paul Kyzivat'; 'Brian Lindsay' > > > Cc: 'Hadriel Kaplan'; 'David Hancock'; martini@ietf.org > > > Subject: Re: [martini] martini-shaken-implicit-registrations :=20 > > > propose P-Associated-URI be removed > > > =20 > > > +1. > > > =20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Friday, January 08, 2010 10:43 AM > > > To: Brian Lindsay > > > Cc: David Hancock; Hadriel Kaplan; martini@ietf.org > > > Subject: Re: [martini] martini-shaken-implicit-registrations :=20 > > > propose P-Associated-URI be removed > > > =20 > > > I agree. This info can be learned more reliably using the=20 > > reg event =20 > > > package. The PBX is probably going to want that anyway. > > > =20 > > > Thanks, > > > Paul > > > =20 > > > Brian Lindsay wrote: > > > > Hi Hadriel / John / David, > > > > > > > > Regarding the martini-shaken-implicit-registrations draft, > > > currently > > > > the draft has the following requirement regarding=20 > support of >=20 > > > P-Associated-URI: > > > > > > > > The Registrar SHOULD indicate all of the implicitly=20 > Registered=20 > > > AoRs in > a P-Associated-URI header field(s) in the 200=20 > > response to=20 > > > the REGISTER, > if it supports [RFC3455]. [OPEN ISSUE:=20 > should we=20 > > > mandate PAU support? > > > > Should we document a legal/compliant means of indicating AoR =20 > > > username > "wildcards"?] > > > > As worded, this is a conditional SHOULD requirement=20 > > (conditional > > > on > > > > whether RFC 3455 is supported by the Registrar), but=20 > there is a =20 > > > question > about whether PAU should be mandated. > > > > > > > > My suggestion would be to remove this requirement=20 > altogether: > > > > > > > > * PAU is not widely utilized outside of IMS and=20 > > hence is likely > > > not > > > > part of most currently deployed SIP PBX > > > > registration-based solutions today > > > > * There haven't been any proposed requirements=20 > tabled to date > > > that > > > > would drive inclusion of this > > > > * In a very early draft of SIP Connect 1.1 ( > 1.5=20 > > years ago), > > > there > > > > was a suggestion of making this optional, but I=20 > > believe none > > > of > > > > the enterprise vendors ever saw any strong value case for > > > doing > > > > anything with the header, hence it was promptly=20 > removed and > > > never > > > > re-surfaced as a requirement in subsequent drafts=20 > > of the spec > > > > * There are diffferences between RFC 3455=20 > > definitions of PAU and > > > IMS > > > > usage of the header that would need to be resolved in the > > > draft > > > > * The assigned numbers for the SIP PBX already need to be > > > > communicated via other means oout of scope of the draft > > > > * There are other technical issues/considerations=20 > > that would be > > > > resolved/considered if it was included, as articulated in > > > > Hadriel's summary slide package of the draft > > > > > > > > Making mandatory would raise a large number of=20 > questions and > > > > considerations, and the potential for implementing=20 > > something in the =20 > > > > network that would never be used by recipiants. It would seem =20 > > > prudent to > simply remove from the draft altogether at=20 > this point. > > > > > > > > Thanks > > > > Brian > > > > > > > > > > > >=20 > > >=20 > -------------------------------------------------------------------- > > > ---- > > > > > > > > _______________________________________________ > > > > martini mailing list > > > > martini@ietf.org > > > > https://www.ietf.org/mailman/listinfo/martini > > > =20 > > > =20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From christer.holmberg@ericsson.com Mon Jan 11 05:53:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FD13A67E2 for ; Mon, 11 Jan 2010 05:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.214, 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 m85tRGtFePrB for ; Mon, 11 Jan 2010 05:53:12 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 886E93A67B2 for ; Mon, 11 Jan 2010 05:53:11 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-60-4b4b2d441905 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 15.03.04178.44D2B4B4; Mon, 11 Jan 2010 14:53:08 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 11 Jan 2010 14:53:07 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "Elwell, John" , Adam Roach Date: Mon, 11 Jan 2010 14:53:07 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP65KxO6rNEx8qRwS919b8/WYnvQAYQ3kQAB8b89AAfvbjAA== Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 13:53:13 -0000 Hi,=20 >I don't think there is anything particularly IMS specific about what I was= saying.=20 >=20 >I can take you back to ISDN days and point you at the work there as well. = DSS1 T reference point procedures assume that=20 >the functionality for dealing with specific extensions is on the PBX side = of the interface.=20 >=20 >Put that functionality back on the public network side of the interface, a= nd you have an access concentrator and Centrex, not a PBX. >=20 >I don't see how a lot of that model (which is essentially a business relat= ionship model at the start) changes with VOIP. I am not an expert of PBXs, but I talked to some people and they told me mo= re or less what Keith also says. I also see no reason why we should change that concept for VoIP. I don't th= ink that is even in the scope of MARTINI to do so. Regards, Christer > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Friday, January 08, 2010 10:29 AM > > To: Adam Roach; Christer Holmberg > > Cc: Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] draft-roach-martini-up-00 > >=20 > > I think Christer's summary is good. The architecture that Keith and=20 > > others are talking about is applicable outside IMS too -=20 > that is what=20 > > the SIP Forum is trying to achieve with SIPconnect - a=20 > means for a PBX=20 > > to register. This was probably a lot clearer with the=20 > earlier domain=20 > > registration draft ("stirred"), but it is still the same principle=20 > > with the current implicit registration draft ("shaken"). > >=20 > > John > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > > Sent: 07 January 2010 22:49 > > > To: Christer Holmberg > > > Cc: martini@ietf.org; Hadriel Kaplan > > > Subject: Re: [martini] draft-roach-martini-up-00 > > >=20 > > > You're spot on in describing the differences in perspectives.=20 > > > I think it > > > comes down to whether you see an application for SIP=20 > outside of IMS=20 > > > architectures. > > >=20 > > > In IMS-derived architectures, you can make the assumptions > > Keith has.=20 > > > In the general case, I don't think they hold. > > >=20 > > > /a > > >=20 > > > On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > > > > Hi, > > > > > > > > I think one of the reason we go over the same thing over > > > and over is because we don't have a common view on the > > "user" concept. > > > > > > > > Adam talks about multiple users, and that using a single > > > REGISTER for those breaks things. Keith (and maybe others) > > seems to be > > > arguing that we are still talking about a SINGLE SIP user. What=20 > > > happens inside the PBX is irrelevant. The PBX users have=20 > a relation=20 > > > with the PBX - the PBX has a relation with the SIP network. > > > > > > > > So, from Keith's perspective things would not be broken, > > > and intermediates in the SIP network do not (at least not by > > > default) need to be aware of individual users behind the PBX. > > > > > > > > But, I may have missunderstood, and in that case I appologize :) > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > > > Sent: 8. tammikuuta 2010 0:23 > > > > To: Hadriel Kaplan > > > > Cc: martini@ietf.org > > > > Subject: Re: [martini] draft-roach-martini-up-00 > > > > > > > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > > > > =20 > > > >> I don't understand why you think using a REGISTER > > > transaction makes it any more or less=20 > architecture-specific than a=20 > > > PUBLISH one. > > > >> > > > >> =20 > > > > That's not what I'm saying. There's been a lot of > > > back-and-forth on this topic that amounts to the same=20 > exchange over=20 > > > and over (not just with you; with several parties). I'm going to=20 > > > replay the dialog in simplified form, because I think=20 > something is=20 > > > getting lost with the flood of email > > > > messages: > > > > > > > > A: "Changing REGISTER in this way can break intermediaries." > > > > B: "But in the architecture MARTINI is considering, it > > > breaks nothing." > > > > A: "The fact that it works in one place does not mean it > > > works everywhere." > > > > > > > > Changing the established meaning of REGISTER can cause > > > problems unless all parties to the transaction understand > > the changes.=20 > > > The fact that no such problem arises in one specific architecture=20 > > > seems to be held out as proof that it must work everywhere. > > Which is > > > the logical equivalent to: > > > > "this particular swan is white, therefore all swans must be > > > white." (cf > > > >=20 > > > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori > > > cal_inference) > > > > > > > > What I'm proposing with PUBLISH isn't a change to > > > established semantics. > > > > In fact, it aligns precisely with established semantics: as > > > I said on the phone, the basic concept of using PUBLISH=20 > to update a=20 > > > Location Service database could be a BCP, since it=20 > requires no new=20 > > > protocol mechanism. Nothing breaks, since the meaning of=20 > everything=20 > > > remains the same. > > > > > > > > Everything else I've proposed so far is properly negotiated > > > SIP protocol extensions using established extension=20 > mechanisms. You=20 > > > could do the same thing with REGISTER, if you really=20 > wanted to, by=20 > > > using both Require and Proxy-Require. > > > > > > > > /a > > > > _______________________________________________ > > > > martini mailing list > > > > martini@ietf.org > > > > https://www.ietf.org/mailman/listinfo/martini > > > > =20 > > >=20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > = From pkyzivat@cisco.com Mon Jan 11 06:43:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090DE28C146 for ; Mon, 11 Jan 2010 06:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.357 X-Spam-Level: X-Spam-Status: No, score=-10.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4alvBChM6zA for ; Mon, 11 Jan 2010 06:43:46 -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 E36643A67B1 for ; Mon, 11 Jan 2010 06:43:46 -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: ApoEADrISkurRN+J/2dsb2JhbADEDZMGhC8E X-IronPort-AV: E=Sophos;i="4.49,256,1262563200"; d="scan'208";a="131413964" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2010 14:43:44 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0BEhiIX005629; Mon, 11 Jan 2010 14:43:44 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 08:43:44 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 08:43:43 -0600 Message-ID: <4B4B391E.5020004@cisco.com> Date: Mon, 11 Jan 2010 09:43:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <31906_1262973559_4B477277_31906_13619_1_9ECCF01B52E7AB408A7EB85352642141ECFF7A@ftrdmel0.rd.francetelecom.fr> <4B47D25C.7030208@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 11 Jan 2010 14:43:43.0833 (UTC) FILETIME=[793A5490:01CA92CC] Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 14:43:48 -0000 DRAGE, Keith (Keith) wrote: > Yes, but in that case why doesn't the enterprise SBC support the PBX end of "the mechanism", rather than the PBX itself. > > Remember that the PBX network as a whole does not need to know about "the mechanism". It is purely local to the interface. IMO the discussion is about a UAC sending a REGISTER request and a UAS processing and responding to a REGISTER request. Within that context, either intervening proxies are supported or not. I think its generally agreed that it is indeed necessary to support intervening proxies. It is true that you might have an SBC that does the REGISTER, and a "pbx" behind it that is oblivious to the register. And in that case I think we can say that the relationship between those two is out of scope. But it is also possible to have a "pbx" that does the REGISTER, and a proxy or SBC between it and the registrar, managed by the enterprise rather than the SP. I don't see how it can matter who is in charge of intermediates between the registering UA and the registrar. (Or how making such a distinction would help anything.) Thanks, Paul > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Saturday, January 09, 2010 12:48 AM >> To: DRAGE, Keith (Keith) >> Cc: bruno.chatras@orange-ftgroup.com; >> john.elwell@siemens-enterprise.com; martini@ietf.org >> Subject: Re: [martini] Requirements - rev1 >> >> >> >> DRAGE, Keith (Keith) wrote: >>> With regard to the intermediate proxies requirement, can we >> limit this to intermediate proxies in the SSP. >>> For the PBX side, I have always considered an such >> mechanism as local to the gateway provided by the PBX, and >> not extending any further into the enterprise. If this >> applies, then it excludes any proxies on the PBX side of the gateway. >> >> Seems to me that argument also works (or actual also >> *doesn't* work) in >> reverse: the "proxies" on the SSP side could be considered as >> a local mechanism to the registrar provided by the SSP. >> >> If you look at it from the SSP side then you want your side >> to have the special treatment but are willing to sweep the >> issues of the other side under the rug. Same goes the other way. >> >> The fact is that its quite possible that the architecture is: >> >> pbx --- enterprise_sbc --- SP_sbc --- SP_other_stuff >> >> And the enterprise_sbc may be sourced independently of the pbx. >> (Though of course we would be happy to sell you both.) >> >> Thanks, >> Paul >> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of >>>> bruno.chatras@orange-ftgroup.com >>>> Sent: Friday, January 08, 2010 5:59 PM >>>> To: john.elwell@siemens-enterprise.com >>>> Cc: martini@ietf.org >>>> Subject: Re: [martini] Requirements - rev1 >>>> >>>> You have included a requirement that the mechanism MUST >> work in the >>>> presence of intermediate "proxies" between the PBX and the SSP's. >>>> Don't we need as well a requirement about the presence of >>>> intermediate enterprise proxies between the PBX and the SIP >>>> terminals, especially when considering inbound requests? >>>> >>>>> -----Message d'origine----- >>>>> De : martini-bounces@ietf.org >>>>> [mailto:martini-bounces@ietf.org] De la part de Elwell, >>>> John Envoyé : >>>>> vendredi 8 janvier 2010 18:46 À : martini@ietf.org Objet : >>>> [martini] >>>>> Requirements - rev1 >>>>> >>>>> Revised following the feedback since yesterday. Please >> continue the >>>>> feedback. >>>>> >>>>> - The mechanism MUST allow the PBX to be responsible for >>>> its AORs and >>>>> to handle requests to those AORs according to its rules. >>>>> - The mechanism MUST allow the PBX to receive requests to >> its AORs >>>>> that originate off-PBX and arrive via the SSP, so that >> the PBX can >>>>> handle those requests according to its rules. >>>>> - The mechanism MUST provide a means whereby the PBX >> knows which of >>>>> its AORs an inbound request is targeted at. >>>>> - The mechanism MUST provide a means of avoiding problems >>>> due to one >>>>> side using the mechanism and the other side not. >>>>> - The mechanism MUST observe SIP backwards compatibility >> principles. >>>>> - The mechanism MUST work in the presence of intermediate >> "proxies" >>>>> between the PBX and the SSP's domain proxy, where those >>>> intermediate >>>>> "proxies" need to be on the path of inbound requests to the PBX. >>>>> - The mechanism MUST work when the PBX obtains its IP address >>>>> dynamically. >>>>> - The mechanism MUST work without requiring the PBX to publish >>>>> reachability information through the DNS. >>>>> >>>>> Also some desiderata: >>>>> - The mechanism SHOULD allow SSPs to exploit its mechanisms for >>>>> providing SIP service to ordinary subscribers in order to >> provide a >>>>> SIP trunking service to PBXs. >>>>> - The mechanism SHOULD scale to PBXs of several thousand AORs. >>>>> - The mechanism SHOULD require relatively modest changes to a >>>>> substantial population of existing SSP and PBX >> implementations, in >>>>> order to encourage a fast market adoption of the standardized >>>>> mechanism. >>>>> >>>>> John >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>> ********************************* >>>> This message and any attachments (the "message") are >> confidential and >>>> intended solely for the addressees. >>>> Any unauthorised use or dissemination is prohibited. >>>> Messages are susceptible to alteration. >>>> France Telecom Group shall not be liable for the message >> if altered, >>>> changed or falsified. >>>> If you are not the intended addressee of this message, >> please cancel >>>> it immediately and inform the sender. >>>> ******************************** >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> From adam@nostrum.com Mon Jan 11 07:10:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F703A6810 for ; Mon, 11 Jan 2010 07:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 zYKAenHuhyVk for ; Mon, 11 Jan 2010 07:10:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3D24A3A67A7 for ; Mon, 11 Jan 2010 07:10:16 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0BF9nqL097196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 09:09:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4B3F3D.2020007@nostrum.com> Date: Mon, 11 Jan 2010 09:09:49 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Christer Holmberg References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> <4B474C3F.7090601@nostrum.com> <4B47A15C.4050708@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Alan Johnston , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 15:10:18 -0000 On 1/11/10 3:15 AM, Christer Holmberg wrote: > IF the PBX is seen as a single user from the SIP network perspective... I don't think this predicate holds in the general case. I think it is specific to a fairly narrow set of network architectures. /a From pkyzivat@cisco.com Mon Jan 11 07:21:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B0E3A6823 for ; Mon, 11 Jan 2010 07:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSynW7r6EGTh for ; Mon, 11 Jan 2010 07:21: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 713BA3A67FB for ; Mon, 11 Jan 2010 07:21: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: ApoEAG/QSkutJV2b/2dsb2JhbADETpMHhC8E X-IronPort-AV: E=Sophos;i="4.49,256,1262563200"; d="scan'208";a="231880290" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2010 15:21:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0BFLaGM032053; Mon, 11 Jan 2010 15:21:36 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:21:36 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 09:21:36 -0600 Message-ID: <4B4B41FF.4060209@cisco.com> Date: Mon, 11 Jan 2010 10:21:35 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> <4B474C3F.7090601@nostrum.com> <4B47A15C.4050708@cisco.com> <4B4B3F3D.2020007@nostrum.com> In-Reply-To: <4B4B3F3D.2020007@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2010 15:21:36.0371 (UTC) FILETIME=[C3C41C30:01CA92D1] Cc: Alan Johnston , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 15:21:46 -0000 This seems to be a scoping issue for the work. Certainly it is an assumption that works for "stirred". I would be willing to accept this as a scope limitation on the work. Getting agreement on the scope here might resolve some of the other issues. Thanks, Paul Adam Roach wrote: > On 1/11/10 3:15 AM, Christer Holmberg wrote: >> IF the PBX is seen as a single user from the SIP network perspective... > > I don't think this predicate holds in the general case. I think it is > specific to a fairly narrow set of network architectures. > > /a > From adam@nostrum.com Mon Jan 11 07:24:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDED3A67EB for ; Mon, 11 Jan 2010 07:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cRAQpmtSCTpS for ; Mon, 11 Jan 2010 07:24:52 -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 38DA53A67CC for ; Mon, 11 Jan 2010 07:24:52 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0BFOjWV098303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 09:24:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4B42BD.6000700@nostrum.com> Date: Mon, 11 Jan 2010 09:24:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: David Hancock References: <4B47C443.6060702@nostrum.com> <9AAEDF491EF7CA48AB587781B8F5D7C60278F54D@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60278F54D@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 15:24:53 -0000 David: I think you've represented my concerns accurately below. I still think that Keith is advocating Flow-1. Keith: can you clarify your position? /a On 1/8/10 6:27 PM, David Hancock wrote: > Adam, > > Just to clarify, you're saying Flow-1 is bad, because it creates a > routing loop. (The following flows assume the IP-PBX has used implicit > registration to bind the enterprise AORs to a single IP-PBX contact > address.) > > ========================= Flow-1 ================================ > > Some network SP Network IP-PBX > ------------ ---------- ------ > [1]INVITE sip:usr1@sp.com --> > > [2]INVITE sip:usr1@sp.com --> > Route: sip: > > [3]<-- INVITE sip:usr1@sp.com > > ================================================================ > > To avoid the routing loop, the SP network must retarget the Request-URI > of [2] so it contains the domain of the IP-PBX, as shown in Flow-2. > > > ========================= Flow-2 ================================ > > Some network SP Network IP-PBX > ------------ ---------- ------ > [1]INVITE sip:usr1@sp.com --> > > [2]INVITE sip:usr1@pbx1.sp.com --> > Route: sip: > > ================================================================ > > My understanding is that Keith's text "...the Request-URI should not be > replaced by the SSP on requests sent to the PBX" wasn't referring to > Flow-2, but to Flow-3, where the SP terminating home proxy retargets the > request to the registered contact address as shown in Flow-3. > > ========================= Flow-3 ================================ > > Some network SP Network IP-PBX > ------------ ---------- ------ > [1]INVITE sip:usr1@sp.com --> > > [2]INVITE sip: --> > > ================================================================ > > My understanding is that Keith is saying that the message routing > procedure in Flow-2 should apply for both "subscription" and "peering" > modes (is that correct Keith?). > > I hope this clarifies and doesn't confuse the issue. > > Thanks > David > > > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> > Behalf > >> Of Adam Roach >> Sent: Friday, January 08, 2010 4:48 PM >> To: DRAGE, Keith (Keith) >> Cc: martini@ietf.org >> Subject: Re: [martini] Requirements - rev1 >> >> On 1/8/10 5:38 PM, DRAGE, Keith (Keith) wrote: >> >>> I would like to see a SHOULD on something like: >>> >>> The mechansism should allow handling of inbound requests and >>> > outbound > >> requests between SSP and PBX to be as common as possible as for a >> > normal > >> peering arrangement (e.g. RFC 3263 based), as far as the PBX is >> > concerned. > >> The handing of requests at the incoming / outgoing gateway in the edge >> > PBX > >> should be common once the mechanism has been applied. >> >>> Essentially this means that the Request-URI should not be replaced >>> > by > >> the SSP on requests sent to the PBX. >> >>> >> No, I don't think this is correct. >> >> Fundamentally, this is a 3261 registrar relationship (regardless of >> whether we use NOTIFY or REGISTER), not a 3263 relationship. In >> particular, what you propose cannot co-exist with the requirement: >> >> - The mechanism MUST provide a means of avoiding problems dueto one >> > side > >> using the mechanism and the other side not. >> >> >> Because a failure to rewrite the URI means that the URI will still >> resolve to the SSP under 3263 rules (since that's how it got there in >> the first place). So, if it sends it to the PBX, and the PBX doesn't >> > use > >> the MARTINI mechanism, it will apply 3263, and route it back to the >> > SSP. > >> The SSP will then apply MARTINI rules and route it to the registered >> PBX. Who will route it to the SSP. Which will then route it to the >> > PBX. > >> And so on. >> >> In particular, I think what you're describing is a requirement, but it >> should be "MUST NOT", instead of SHOULD." >> >> /a >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> From christer.holmberg@ericsson.com Mon Jan 11 07:40:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BD73A67F2 for ; Mon, 11 Jan 2010 07:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.190, 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 P+0Mg--9d932 for ; Mon, 11 Jan 2010 07:40:16 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9B4723A67EB for ; Mon, 11 Jan 2010 07:40:15 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-e2-4b4b465b1e6e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 5F.7C.04178.B564B4B4; Mon, 11 Jan 2010 16:40:12 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 11 Jan 2010 16:40:11 +0100 From: Christer Holmberg To: Adam Roach Date: Mon, 11 Jan 2010 16:38:40 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqS0C2voOKgdSzsT++FhocccT35EAAA/jQw Message-ID: References: <4B44B489.6080708@nostrum.com> <4B454064.4000107@nostrum.com> <4B45F429.3080802@nostrum.com> <4B460578.4050601@nostrum.com> <4B46102F.9000006@sipstation.com> <4B462820.4010702@nostrum.com> <4B4746A8.2030602@sipstation.com> <4B474C3F.7090601@nostrum.com> <4B47A15C.4050708@cisco.com> , <4B4B3F3D.2020007@nostrum.com> In-Reply-To: <4B4B3F3D.2020007@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Alan Johnston , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 15:40:17 -0000 Hi, >>IF the PBX is seen as a single user from the SIP network perspective... > >I don't think this predicate holds in the general case. I think it is spec= ific to a fairly narrow set of network >architectures. My understanding is that it applies for PBXs in general, and is not specifi= c to the core network architecture. Regards, Christer= From bernard_aboba@hotmail.com Mon Jan 11 08:16:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D1B3A6896 for ; Mon, 11 Jan 2010 08:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.630, 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 iVaADwRAGBk7 for ; Mon, 11 Jan 2010 08:16:47 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by core3.amsl.com (Postfix) with ESMTP id 3D2EE3A6880 for ; Mon, 11 Jan 2010 08:16:47 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 08:16:45 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 11 Jan 2010 08:17:14 -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: AcqS07vMbailEVW2QCytWqJSgtX45QABcAoA Content-Language: en-us X-OriginalArrivalTime: 11 Jan 2010 16:16:45.0081 (UTC) FILETIME=[77E93090:01CA92D9] Subject: [martini] FW: draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 16:16:48 -0000 -----Original Message----- From: Francois Audet [mailto:francois.audet@skypelabs.com] Sent: Monday, January 11, 2010 7:35 AM To: Christer Holmberg Cc: DRAGE, Keith (Keith); Elwell, John; Adam Roach; martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 I agree On Jan 11, 2010, at 5:53, Christer Holmberg wrote: > > Hi, > >> I don't think there is anything particularly IMS specific about >> what I was saying. >> >> I can take you back to ISDN days and point you at the work there as >> well. DSS1 T reference point procedures assume that >> the functionality for dealing with specific extensions is on the >> PBX side of the interface. >> >> Put that functionality back on the public network side of the >> interface, and you have an access concentrator and Centrex, not a >> PBX. >> >> I don't see how a lot of that model (which is essentially a >> business relationship model at the start) changes with VOIP. > > I am not an expert of PBXs, but I talked to some people and they > told me more or less what Keith also says. > > I also see no reason why we should change that concept for VoIP. I > don't think that is even in the scope of MARTINI to do so. > > Regards, > > Christer From francois.audet@skypelabs.com Mon Jan 11 07:35:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004C43A67AA for ; Mon, 11 Jan 2010 07:35: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 QUClwTCwGqOt for ; Mon, 11 Jan 2010 07:35:40 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 51BA73A67FB for ; Mon, 11 Jan 2010 07:35:40 -0800 (PST) Received: by pxi16 with SMTP id 16so6709307pxi.29 for ; Mon, 11 Jan 2010 07:35:35 -0800 (PST) Received: by 10.140.56.19 with SMTP id e19mr8296454rva.63.1263224135309; Mon, 11 Jan 2010 07:35:35 -0800 (PST) Received: from ?10.22.172.128? ([166.205.137.11]) by mx.google.com with ESMTPS id 22sm1909167pzk.2.2010.01.11.07.35.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 07:35:34 -0800 (PST) References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com> <00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com> <1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com> <4B46196F.4020006@nostrum.com> <4B465EC9.5050709@nostrum.com> <4B4664C4.2060403@nostrum.com> Message-Id: <5B8BBFBC-7447-4D98-B83F-9B4182E1E517@skypelabs.com> From: Francois Audet To: Christer Holmberg In-Reply-To: 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: Mon, 11 Jan 2010 07:35:22 -0800 X-Mailman-Approved-At: Mon, 11 Jan 2010 09:37:40 -0800 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 15:35:42 -0000 I agree On Jan 11, 2010, at 5:53, Christer Holmberg wrote: > > Hi, > >> I don't think there is anything particularly IMS specific about >> what I was saying. >> >> I can take you back to ISDN days and point you at the work there as >> well. DSS1 T reference point procedures assume that >> the functionality for dealing with specific extensions is on the >> PBX side of the interface. >> >> Put that functionality back on the public network side of the >> interface, and you have an access concentrator and Centrex, not a >> PBX. >> >> I don't see how a lot of that model (which is essentially a >> business relationship model at the start) changes with VOIP. > > I am not an expert of PBXs, but I talked to some people and they > told me more or less what Keith also says. > > I also see no reason why we should change that concept for VoIP. I > don't think that is even in the scope of MARTINI to do so. > > Regards, > > Christer > > > > > >>> -----Original Message----- >>> From: martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John >>> Sent: Friday, January 08, 2010 10:29 AM >>> To: Adam Roach; Christer Holmberg >>> Cc: Hadriel Kaplan; martini@ietf.org >>> Subject: Re: [martini] draft-roach-martini-up-00 >>> >>> I think Christer's summary is good. The architecture that Keith and >>> others are talking about is applicable outside IMS too - >> that is what >>> the SIP Forum is trying to achieve with SIPconnect - a >> means for a PBX >>> to register. This was probably a lot clearer with the >> earlier domain >>> registration draft ("stirred"), but it is still the same principle >>> with the current implicit registration draft ("shaken"). >>> >>> John >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >>>> Sent: 07 January 2010 22:49 >>>> To: Christer Holmberg >>>> Cc: martini@ietf.org; Hadriel Kaplan >>>> Subject: Re: [martini] draft-roach-martini-up-00 >>>> >>>> You're spot on in describing the differences in perspectives. >>>> I think it >>>> comes down to whether you see an application for SIP >> outside of IMS >>>> architectures. >>>> >>>> In IMS-derived architectures, you can make the assumptions >>> Keith has. >>>> In the general case, I don't think they hold. >>>> >>>> /a >>>> >>>> On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> I think one of the reason we go over the same thing over >>>> and over is because we don't have a common view on the >>> "user" concept. >>>>> >>>>> Adam talks about multiple users, and that using a single >>>> REGISTER for those breaks things. Keith (and maybe others) >>> seems to be >>>> arguing that we are still talking about a SINGLE SIP user. What >>>> happens inside the PBX is irrelevant. The PBX users have >> a relation >>>> with the PBX - the PBX has a relation with the SIP network. >>>>> >>>>> So, from Keith's perspective things would not be broken, >>>> and intermediates in the SIP network do not (at least not by >>>> default) need to be aware of individual users behind the PBX. >>>>> >>>>> But, I may have missunderstood, and in that case I appologize :) >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >>>>> Sent: 8. tammikuuta 2010 0:23 >>>>> To: Hadriel Kaplan >>>>> Cc: martini@ietf.org >>>>> Subject: Re: [martini] draft-roach-martini-up-00 >>>>> >>>>> On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: >>>>> >>>>>> I don't understand why you think using a REGISTER >>>> transaction makes it any more or less >> architecture-specific than a >>>> PUBLISH one. >>>>>> >>>>>> >>>>> That's not what I'm saying. There's been a lot of >>>> back-and-forth on this topic that amounts to the same >> exchange over >>>> and over (not just with you; with several parties). I'm going to >>>> replay the dialog in simplified form, because I think >> something is >>>> getting lost with the flood of email >>>>> messages: >>>>> >>>>> A: "Changing REGISTER in this way can break intermediaries." >>>>> B: "But in the architecture MARTINI is considering, it >>>> breaks nothing." >>>>> A: "The fact that it works in one place does not mean it >>>> works everywhere." >>>>> >>>>> Changing the established meaning of REGISTER can cause >>>> problems unless all parties to the transaction understand >>> the changes. >>>> The fact that no such problem arises in one specific architecture >>>> seems to be held out as proof that it must work everywhere. >>> Which is >>>> the logical equivalent to: >>>>> "this particular swan is white, therefore all swans must be >>>> white." (cf >>>>> >>>> http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori >>>> cal_inference) >>>>> >>>>> What I'm proposing with PUBLISH isn't a change to >>>> established semantics. >>>>> In fact, it aligns precisely with established semantics: as >>>> I said on the phone, the basic concept of using PUBLISH >> to update a >>>> Location Service database could be a BCP, since it >> requires no new >>>> protocol mechanism. Nothing breaks, since the meaning of >> everything >>>> remains the same. >>>>> >>>>> Everything else I've proposed so far is properly negotiated >>>> SIP protocol extensions using established extension >> mechanisms. You >>>> could do the same thing with REGISTER, if you really >> wanted to, by >>>> using both Require and Proxy-Require. >>>>> >>>>> /a >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Mon Jan 11 15:57:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896E93A6943 for ; Mon, 11 Jan 2010 15:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.668, 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 heF-x3F3Hhzh for ; Mon, 11 Jan 2010 15:57:19 -0800 (PST) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by core3.amsl.com (Postfix) with ESMTP id A237D3A689B for ; Mon, 11 Jan 2010 15:57:19 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.71]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Jan 2010 15:57:17 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 11 Jan 2010 15:57:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01CA92D6.BF488CE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTGZzJmOcaEOV7TPegvnwcvmisTAAABwQA Content-Language: en-us X-OriginalArrivalTime: 11 Jan 2010 23:57:17.0803 (UTC) FILETIME=[CE4BF3B0:01CA9319] Subject: [martini] MARTINI Doodle polls: Please participate! X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 23:57:22 -0000 ------=_NextPart_000_01D9_01CA92D6.BF488CE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We are going to wrap up the MARTINI Doodle Poll for dates/times for Virtual Interims II & III tomorrow, so if you haven't weighed in yet, please do so ASAP: Poll for 2nd Virtual Interim (Week of January 25, 2010): http://www.doodle.com/3r4wi9kbrnrx4ypk Poll for 3rd Virtual Interim (Week of February 8, 2010): http://www.doodle.com/7q5s2sm9wwb8md2n Thanks! ------=_NextPart_000_01D9_01CA92D6.BF488CE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

We are going to wrap up the MARTINI Doodle Poll for dates/times for Virtual Interims II & III tomorrow,

so if you haven’t weighed in yet, please do = so ASAP:

Poll for 2nd Virtual Interim (Week of January 25, 2010): http://www.doodle.com/3r4= wi9kbrnrx4ypk

Poll for 3rd Virtual Interim (Week of February 8, 2010): http://www.doodle.com/7q5= s2sm9wwb8md2n

Thanks!

------=_NextPart_000_01D9_01CA92D6.BF488CE0-- From BLINDSAY@nortel.com Tue Jan 12 08:21:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF2A3A6A1F for ; Tue, 12 Jan 2010 08:21: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=[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 p4BxwxFnph+4 for ; Tue, 12 Jan 2010 08:21:11 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 85C313A6A14 for ; Tue, 12 Jan 2010 08:21:11 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0CGKXM04262; Tue, 12 Jan 2010 16:20:34 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jan 2010 11:20:21 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqP65KxO6rNEx8qRwS919b8/WYnvQAYQ3kQANU9+wA= References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com> From: "Brian Lindsay" To: "Elwell, John" , "Adam Roach" , "Christer Holmberg" Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 16:21:13 -0000 Hi, One comment on this and shaken vs stirred: For the registration-based approaches there are several clear interface principles that have emerged: - The SIP PBX REGISTERs using an explicit AoR, assigned by the Service Provider, that represents the SIP PBX - For requests sent to the SIP PBX, the Request-URI is not overwritten with the contact provided at registration. However, the domain in the SIP URI in the Request-URI would contain the domain associated with the SIP PBX. This provides equivalency to RFC3263 peering approaches for signalling. - The drafts also propose some additional signalling information to explicitly identify in the REGISTER request/response that this behavior is requested/provided. The IMS-style implicit registration approach described in Martini-shaken describes one possible network implememntation for registration. By this I mean there is the concept of an implicit registration set, which in this case would contain AoRs representing E.164 numbers or ranges, and likely also a wildcarded AoR for the SIP PBX domain. There is a location service database containing all of these AoRs which is updated with the contact info provided at registration. I think it should also be possible to implement something quite different on the network side which still satisfies the same interface requirements but does not technically/formally use IMS-style "implicit registration" as the basis of the network implementation. For example, one might have a network implementation which includes a separate database that effectively maps E.164 numbers/ranges to domains (e.g. an ENUM type approach). In such an approach, the E.164 numbers/ranges are technically not part of an IMS-style implicit registration set per se, and the E.164 numbers wouldn't be in the formal location service database as AoRs. From this perspective, the actual internal network implementation starts to look a lot more like "domain" registration. There is a section in Martini-shaken which actually allows for alternate implementations as long as the external interface behavior is satisfied: " 4.4. Registrar Behavior=20 =20 This document uses the same logical location service database=20 concept of [RFC3261] residing in the Registrar, for the purpose of=20 describing the behavior of the mechanism in this document. Specific=20 implementations need not follow this data structure, so long as they=20 maintain the same logical external behavior. " =20 So I believe we need a clear set of interface/behavioral requirements for registration/routing, but we do not need to necessarily dictate or assume what is technically an IMS-like implicit registration implementation in the network. Is this generally agreed? If so, does "implicit" registration carry too much "baggage" in this context? Thoughts? Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, January 08, 2010 5:29 AM To: Adam Roach; Christer Holmberg Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 I think Christer's summary is good. The architecture that Keith and others are talking about is applicable outside IMS too - that is what the SIP Forum is trying to achieve with SIPconnect - a means for a PBX to register. This was probably a lot clearer with the earlier domain registration draft ("stirred"), but it is still the same principle with the current implicit registration draft ("shaken"). John > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 07 January 2010 22:49 > To: Christer Holmberg > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > You're spot on in describing the differences in perspectives.=20 > I think it > comes down to whether you see an application for SIP outside of IMS=20 > architectures. >=20 > In IMS-derived architectures, you can make the assumptions Keith has.=20 > In the general case, I don't think they hold. >=20 > /a >=20 > On 1/7/10 16:39, Jan 7, Christer Holmberg wrote: > > Hi, > > > > I think one of the reason we go over the same thing over > and over is because we don't have a common view on the "user" concept. > > > > Adam talks about multiple users, and that using a single > REGISTER for those breaks things. Keith (and maybe others) seems to be > arguing that we are still talking about a SINGLE SIP user. What=20 > happens inside the PBX is irrelevant. The PBX users have a relation=20 > with the PBX - the PBX has a relation with the SIP network. > > > > So, from Keith's perspective things would not be broken, > and intermediates in the SIP network do not (at least not by > default) need to be aware of individual users behind the PBX. > > > > But, I may have missunderstood, and in that case I appologize :) > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 8. tammikuuta 2010 0:23 > > To: Hadriel Kaplan > > Cc: martini@ietf.org > > Subject: Re: [martini] draft-roach-martini-up-00 > > > > On 1/7/10 12:56, Jan 7, Hadriel Kaplan wrote: > > =20 > >> I don't understand why you think using a REGISTER > transaction makes it any more or less architecture-specific than a=20 > PUBLISH one. > >> > >> =20 > > That's not what I'm saying. There's been a lot of > back-and-forth on this topic that amounts to the same exchange over=20 > and over (not just with you; with several parties). I'm going to=20 > replay the dialog in simplified form, because I think something is=20 > getting lost with the flood of email > > messages: > > > > A: "Changing REGISTER in this way can break intermediaries." > > B: "But in the architecture MARTINI is considering, it > breaks nothing." > > A: "The fact that it works in one place does not mean it > works everywhere." > > > > Changing the established meaning of REGISTER can cause > problems unless all parties to the transaction understand the changes. > The fact that no such problem arises in one specific architecture=20 > seems to be held out as proof that it must work everywhere. Which is=20 > the logical equivalent to: > > "this particular swan is white, therefore all swans must be > white." (cf > >=20 > http://en.wikipedia.org/wiki/Falsifiability#Inductive_categori > cal_inference) > > > > What I'm proposing with PUBLISH isn't a change to > established semantics. > > In fact, it aligns precisely with established semantics: as > I said on the phone, the basic concept of using PUBLISH to update a=20 > Location Service database could be a BCP, since it requires no new=20 > protocol mechanism. Nothing breaks, since the meaning of everything=20 > remains the same. > > > > Everything else I've proposed so far is properly negotiated > SIP protocol extensions using established extension mechanisms. You=20 > could do the same thing with REGISTER, if you really wanted to, by=20 > using both Require and Proxy-Require. > > > > /a > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > =20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Tue Jan 12 09:20:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF7628B56A for ; Tue, 12 Jan 2010 09:20:38 -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, 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 vcAvYKtNw6QP for ; Tue, 12 Jan 2010 09:20:37 -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 A72113A67AA for ; Tue, 12 Jan 2010 09:20:36 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0CHKRSp022074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 11:20:28 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4CAF5B.6010303@nostrum.com> Date: Tue, 12 Jan 2010 11:20:27 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Brian Lindsay References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------030402050907060408030405" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:20:38 -0000 This is a multi-part message in MIME format. --------------030402050907060408030405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/12/10 10:20, Jan 12, Brian Lindsay wrote: > For the registration-based approaches there are several clear > interface principles that have emerged: > > ... > > - For requests sent to the SIP PBX, the Request-URI is not overwritten > with the contact provided at registration. While I agree that this is in the nature of the solutions that have been proposed, I believe it is a major flaw in them, and the source of over half of the problems described in the mixing-problems document. > However, the domain in the > SIP URI in the Request-URI would contain the domain associated with the > SIP PBX. This provides equivalency to RFC3263 peering approaches for > signalling. > Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean: 1. A domain that doesn't exist in a domain name registry anywhere 2. A domain that, while properly registered with a domain name registry, does not exist in DNS 3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures 4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures Each of these has its own set of issues; however (as we were discussing yesterday and last week), I think that #3 has a set of particularly intractable issues that make it infeasible for deployment in the Internet. > For example, one might have a network implementation which includes a > separate database that effectively maps E.164 numbers/ranges to domains > (e.g. an ENUM type approach). In such an approach, the E.164 > numbers/ranges are technically not part of an IMS-style implicit > registration set per se, and the E.164 numbers wouldn't be in the formal > location service database as AoRs. From this perspective, the actual > internal network implementation starts to look a lot more like "domain" > registration. > In fact, what you've described starts to look an awful lot like a simplified version of RFC 3219. ;-) > So I believe we need a clear set of interface/behavioral requirements > for registration/routing, but we do not need to necessarily dictate or > assume what is technically an IMS-like implicit registration > implementation in the network. Is this generally agreed? If so, does > "implicit" registration carry too much "baggage" in this context? > Thoughts? > I think that the implicit approach pursued so far does suffer from some significant shortcomings that go away once the URIs being registered are explicit in the request. This is true regardless of the request method we use. /a --------------030402050907060408030405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/12/10 10:20, Jan 12, Brian Lindsay wrote: 
  For the registration-based approaches there are several clear
interface principles that have emerged:

...

- For requests sent to the SIP PBX, the Request-URI is not overwritten
with the contact provided at registration.

While I agree that this is in the nature of the solutions that have been proposed, I believe it is a major flaw in them, and the source of over half of the problems described in the mixing-problems document.

 However, the domain in the
SIP URI in the Request-URI would contain the domain associated with the
SIP PBX. This provides equivalency to RFC3263 peering approaches for
signalling.

Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean:
  1. A domain that doesn't exist in a domain name registry anywhere
  2. A domain that, while properly registered with a domain name registry, does not exist in DNS
  3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures
  4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures

Each of these has its own set of issues; however (as we were discussing yesterday and last week), I think that #3 has a set of particularly intractable issues that make it infeasible for deployment in the Internet.


For example, one might have a network implementation which includes a
separate database that effectively maps E.164 numbers/ranges to domains
(e.g. an ENUM type approach). In such an approach, the E.164
numbers/ranges are technically not part of an IMS-style implicit
registration set per se, and the E.164 numbers wouldn't be in the formal
location service database as AoRs. From this perspective, the actual
internal network implementation starts to look a lot more like "domain"
registration.

In fact, what you've described starts to look an awful lot like a simplified version of RFC 3219. ;-)

  So I believe we need a clear set of interface/behavioral requirements
for registration/routing, but we do not need to necessarily dictate or
assume what is technically an IMS-like implicit registration
implementation in the network. Is this generally agreed? If so, does
"implicit" registration carry too much "baggage" in this context?
Thoughts?

I think that the implicit approach pursued so far does suffer from some significant shortcomings that go away once the URIs being registered are explicit in the request. This is true regardless of the request method we use.

/a
--------------030402050907060408030405-- From bernard_aboba@hotmail.com Tue Jan 12 10:41:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF3E3A68CF for ; Tue, 12 Jan 2010 10:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 lFKXNu8houQg for ; Tue, 12 Jan 2010 10:41:51 -0800 (PST) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by core3.amsl.com (Postfix) with ESMTP id A93503A6915 for ; Tue, 12 Jan 2010 10:41:48 -0800 (PST) Received: from BLU137-DS5 ([65.55.111.71]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 10:41:46 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 12 Jan 2010 10:41:45 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01CA9373.D617DA50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTtuQAZbC0xslOQfuCnB4YpJkCcg== Content-Language: en-us X-OriginalArrivalTime: 12 Jan 2010 18:41:46.0360 (UTC) FILETIME=[E4B0BF80:01CA93B6] Subject: [martini] MARTINI Virtual Interim II Announcement X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:41:53 -0000 ------=_NextPart_000_0268_01CA9373.D617DA50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The MARTINI WG will hold its second Virtual Interim on Tuesday, January 26, 2010 from 9 AM - 11 AM Pacific Time. Topics will include . Requirements. . Operator perspectives. . Solution proposals. Details on the conference parameters will be available on the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html) ------=_NextPart_000_0268_01CA9373.D617DA50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The MARTINI WG will hold its second Virtual Interim = on Tuesday, January 26, 2010 from 9 AM – 11 AM Pacific Time.

 

Topics will include

 

·         Requirements.

·         Operator perspectives.

·         Solution proposals. 

 

Details on the conference parameters will be = available on the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html= )

 

------=_NextPart_000_0268_01CA9373.D617DA50-- From bernard_aboba@hotmail.com Tue Jan 12 10:46:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AA83A6A16 for ; Tue, 12 Jan 2010 10:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_40=-0.185, 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 kGQnY23lgw4m for ; Tue, 12 Jan 2010 10:46:51 -0800 (PST) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id 274573A6AC8 for ; Tue, 12 Jan 2010 10:46:51 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 10:46:48 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 12 Jan 2010 10:46:47 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028F_01CA9374.8A5C13A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTt5gRy+ita7yVQweJhxDz75qwzg== Content-Language: en-us X-OriginalArrivalTime: 12 Jan 2010 18:46:48.0837 (UTC) FILETIME=[98FB1350:01CA93B7] Subject: [martini] MARTINI Virtual Interim III Announcement X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 18:46:53 -0000 ------=_NextPart_000_028F_01CA9374.8A5C13A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The MARTINI WG will hold its third Virtual Interim on Tuesday, February 9, 2010 from 8 AM - 10 AM Pacific Time. The Agenda and conference parameters will be announced on the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html) ------=_NextPart_000_028F_01CA9374.8A5C13A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The MARTINI WG will hold its third Virtual Interim = on Tuesday, February 9, 2010 from 8 AM – 10 AM Pacific Time. =

 

 

The Agenda and conference parameters will be = announced on the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html= )

 

 

------=_NextPart_000_028F_01CA9374.8A5C13A0-- From bernard_aboba@hotmail.com Tue Jan 12 12:47:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C4D3A6899 for ; Tue, 12 Jan 2010 12:47:36 -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.465, BAYES_40=-0.185, 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 bkPC11uCxw92 for ; Tue, 12 Jan 2010 12:47:33 -0800 (PST) Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by core3.amsl.com (Postfix) with ESMTP id 9A2B73A67E6 for ; Tue, 12 Jan 2010 12:47:33 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 12:47:31 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 12 Jan 2010 12:47:29 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C6_01CA9385.66BA76B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTyHSlqsV0x347Qyia1Gie+x8frw== Content-Language: en-us X-OriginalArrivalTime: 12 Jan 2010 20:47:31.0350 (UTC) FILETIME=[75DADB60:01CA93C8] Subject: [martini] Virtual Interim II Agenda Solicitation X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 20:47:36 -0000 ------=_NextPart_000_02C6_01CA9385.66BA76B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The second MARTINI Virtual Interim will be taking place on Tuesday, January 26, 2010 from 9 AM to 11 AM Pacific Time. The topics for the second virtual interim include: . Requirements. . Operator perspectives. . Solution proposals. We would now like to solicit items for the agenda. If you have an item you'd like to discuss, please send a request to myself or Spencer ASAP. ------=_NextPart_000_02C6_01CA9385.66BA76B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The = second MARTINI Virtual Interim will be taking place on Tuesday, January 26, = 2010 from  9 AM to 11 AM Pacific Time.    

The = topics for the second virtual interim include:

·         Requirements.

·         Operator perspectives.

·         Solution proposals.  =  

We = would now like to solicit items for the agenda.  If you have an item = you’d like to discuss, please send a request to myself or Spencer ASAP. =

 

 

------=_NextPart_000_02C6_01CA9385.66BA76B0-- From root@core3.amsl.com Tue Jan 12 15:30:02 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7E76B3A6894; Tue, 12 Jan 2010 15:30:02 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100112233002.7E76B3A6894@core3.amsl.com> Date: Tue, 12 Jan 2010 15:30:02 -0800 (PST) Cc: martini@ietf.org Subject: [martini] MARTINI WG Virtual Interim II X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 23:30:02 -0000 The MARTINI WG will hold its second Virtual Interim on Tuesday, January 26, 2010 from 9 AM - 11 AM Pacific Time. Topics will include Requirements. Operator perspectives. Solution proposals. Agenda, slides and webex url and conference call dial-in details will be posted to: http://www.ietf.org/mail-archive/web/martini/current/maillist.html From root@core3.amsl.com Tue Jan 12 15:45:02 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 36E773A68B6; Tue, 12 Jan 2010 15:45:02 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100112234502.36E773A68B6@core3.amsl.com> Date: Tue, 12 Jan 2010 15:45:02 -0800 (PST) Cc: martini@ietf.org Subject: [martini] MARTINI WG Virtual Interim III X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 23:45:02 -0000 The MARTINI WG will hold its third Virtual Interim on Tuesday, February 9, 2010 from 8 AM - 10 AM Pacific Time. Agenda, slides and webex url and conference call dial-in details will be posted to: http://www.ietf.org/mail-archive/web/martini/current/maillist.html From bernard_aboba@hotmail.com Tue Jan 12 18:46:37 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2515A3A6881 for ; Tue, 12 Jan 2010 18:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[AWL=-1.770, BAYES_50=0.001, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=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 E-kHfvyXfFVT for ; Tue, 12 Jan 2010 18:46:36 -0800 (PST) Received: from blu0-omc2-s31.blu0.hotmail.com (blu0-omc2-s31.blu0.hotmail.com [65.55.111.106]) by core3.amsl.com (Postfix) with ESMTP id 079DF3A67F2 for ; Tue, 12 Jan 2010 18:46:35 -0800 (PST) Received: from BLU137-W9 ([65.55.111.72]) by blu0-omc2-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 18:46:33 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_226dd1c3-c1f0-4e52-8a1b-395c290e16b4_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Tue, 12 Jan 2010 18:46:33 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jan 2010 02:46:33.0619 (UTC) FILETIME=[9E0C3E30:01CA93FA] Subject: [martini] Draft of MARTINI Virtual Interim I Minutes X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 02:46:37 -0000 --_226dd1c3-c1f0-4e52-8a1b-395c290e16b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are available here: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/MARTIN-Virtual-I-Minute= s.txt Comments/edits/additions welcome.=20 EMAILING FOR THE LEAST BAD (WHICH IS KINDA GOOD) Join me = --_226dd1c3-c1f0-4e52-8a1b-395c290e16b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are available here:
http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/= MARTIN-Virtual-I-Minutes.txt

Comments/edits/additions welcome.
<= br>
3D"i'm" EMAILING FOR THE LEAST BAD (WHIC= H IS KINDA GOOD)
Join me=
= --_226dd1c3-c1f0-4e52-8a1b-395c290e16b4_-- From BLINDSAY@nortel.com Tue Jan 12 19:33:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 460953A6936 for ; Tue, 12 Jan 2010 19:33:29 -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=[AWL=-0.000, 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 GRIWbUCvN9wA for ; Tue, 12 Jan 2010 19:33:28 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CDCF23A68FE for ; Tue, 12 Jan 2010 19:33:27 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0D3Wmu09087; Wed, 13 Jan 2010 03:32: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_01CA9400.F4316678" Date: Tue, 12 Jan 2010 22:31:53 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> In-Reply-To: <4B4CAF5B.6010303@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqTq5DOP52c6p0nTaSm35DIEUSiTwAUKMJw References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com> <4B4CAF5B.6010303@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 03:33:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9400.F4316678 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Comments inline below.... ________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, January 12, 2010 12:20 PM To: Lindsay, Brian (CAR:AR00) Cc: Elwell, John; Christer Holmberg; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 On 1/12/10 10:20, Jan 12, Brian Lindsay wrote:=20 For the registration-based approaches there are several clear interface principles that have emerged: =09 ... =09 - For requests sent to the SIP PBX, the Request-URI is not overwritten with the contact provided at registration. While I agree that this is in the nature of the solutions that have been proposed, I believe it is a major flaw in them, and the source of over half of the problems described in the mixing-problems document. However, the domain in the SIP URI in the Request-URI would contain the domain associated with the SIP PBX. This provides equivalency to RFC3263 peering approaches for signalling. =20 Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean: 1. A domain that doesn't exist in a domain name registry anywhere =09 2. A domain that, while properly registered with a domain name registry, does not exist in DNS=20 3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures =09 4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures=20 [Lindsay, Brian] More than one of these might be possible, but I was basically refering to the principle illustrated in David's "Flow-2" in the following post from last week: =20 http://www.ietf.org/mail-archive/web/martini/current/msg00166.html Each of these has its own set of issues; however (as we were discussing yesterday and last week), I think that #3 has a set of particularly intractable issues that make it infeasible for deployment in the Internet. For example, one might have a network implementation which includes a separate database that effectively maps E.164 numbers/ranges to domains (e.g. an ENUM type approach). In such an approach, the E.164 numbers/ranges are technically not part of an IMS-style implicit registration set per se, and the E.164 numbers wouldn't be in the formal location service database as AoRs. From this perspective, the actual internal network implementation starts to look a lot more like "domain" registration. =20 In fact, what you've described starts to look an awful lot like a simplified version of RFC 3219. ;-) [Lindsay, Brian] Ah Interesting. My example here was just to show that there could be multiple possible network implementations which can support the same interfaces as proposed in Martini-Shaken, but don't actually require the E.164 numbers/ranges associated with the SIP PBX / enterprise to be part of an implicit registration set and included in an RFC3261 local service data database.=20 So I believe we need a clear set of interface/behavioral requirements for registration/routing, but we do not need to necessarily dictate or assume what is technically an IMS-like implicit registration implementation in the network. Is this generally agreed? If so, does "implicit" registration carry too much "baggage" in this context? Thoughts? =20 I think that the implicit approach pursued so far does suffer from some significant shortcomings that go away once the URIs being registered are explicit in the request. This is true regardless of the request method we use. /a ------_=_NextPart_001_01CA9400.F4316678 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
   Comments inline below....

From: Adam Roach = [mailto:adam@nostrum.com]=20
Sent: Tuesday, January 12, 2010 12:20 PM
To: = Lindsay, Brian=20 (CAR:AR00)
Cc: Elwell, John; Christer Holmberg; Hadriel = Kaplan;=20 martini@ietf.org
Subject: Re: [martini]=20 draft-roach-martini-up-00

On 1/12/10 10:20, Jan 12, Brian Lindsay wrote:=20 
  For the registration-based approaches =
there are several clear
interface principles that have emerged:

...

- For requests sent to the SIP PBX, the Request-URI is not overwritten
with the contact provided at registration.

While I = agree=20 that this is in the nature of the solutions that have been proposed, I = believe=20 it is a major flaw in them, and the source of over half of the problems=20 described in the mixing-problems document.

 However, the domain in the
SIP URI in the Request-URI would contain the domain associated with the
SIP PBX. This provides equivalency to RFC3263 peering approaches for
signalling.

Given the context of what has been discussed so = far,=20 what you say here is too vague for me to figure out whether it is = correct. When=20 you say "the domain associated with the SIP PBX," do you mean:
  1. A domain that doesn't exist in a domain name registry anywhere
  2. A domain that, while properly registered with a domain name = registry, does=20 not exist in DNS=20
  3. A domain that exists in the global DNS, and which routes to the = SSP if=20 someone applies 3263 procedures
  4. A domain that exists in the global DNS, and which routes to the = PBX if=20 someone applies 3263 procedures
[Lindsay, Brian]  More than one of these might be = possible, but I=20 was basically refering to the principle illustrated in David's "Flow-2" = in the=20 following post from last week:
 
http://www.ietf.org/mail-archive/web/martini/current/msg00166.html=

Each=20 of these has its own set of issues; however (as we were discussing = yesterday and=20 last week), I think that #3 has a set of particularly intractable issues = that=20 make it infeasible for deployment in the Internet.


For example, one might have a network =
implementation which includes a
separate database that effectively maps E.164 numbers/ranges to domains
(e.g. an ENUM type approach). In such an approach, the E.164
numbers/ranges are technically not part of an IMS-style implicit
registration set per se, and the E.164 numbers wouldn't be in the formal
location service database as AoRs. From this perspective, the actual
internal network implementation starts to look a lot more like "domain"
registration.

In fact, what you've described starts to look an awful lot like = a=20 simplified version of RFC 3219. ;-)
[Lindsay, Brian]  Ah Interesting. My example here was = just to=20 show that there could be multiple possible network implementations = which=20 can support the same interfaces as proposed in Martini-Shaken, but = don't=20 actually require the E.164 numbers/ranges associated with the SIP = PBX /=20 enterprise to be part of an implicit registration set and included=20 in an RFC3261 local service data database. = 
  So I believe we need a clear set of =
interface/behavioral requirements
for registration/routing, but we do not need to necessarily dictate or
assume what is technically an IMS-like implicit registration
implementation in the network. Is this generally agreed? If so, does
"implicit" registration carry too much "baggage" in this context?
Thoughts?

I think that the implicit approach pursued so = far does=20 suffer from some significant shortcomings that go away once the URIs = being=20 registered are explicit in the request. This is true regardless of the = request=20 method we use.

/a
------_=_NextPart_001_01CA9400.F4316678-- From adam@nostrum.com Wed Jan 13 05:47:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64BC3A69C5 for ; Wed, 13 Jan 2010 05:47:52 -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, 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 A278HtsZvkcF for ; Wed, 13 Jan 2010 05:47:51 -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 555C83A67D8 for ; Wed, 13 Jan 2010 05:47:51 -0800 (PST) Received: from hydra-3.local (ppp-70-242-121-134.dsl.rcsntx.swbell.net [70.242.121.134]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0DDlgmT019429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 07:47:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4DCEFE.6070300@nostrum.com> Date: Wed, 13 Jan 2010 07:47:42 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Brian Lindsay References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com> <4B4CAF5B.6010303@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------040903030609010805070308" Received-SPF: pass (nostrum.com: 70.242.121.134 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 13:47:53 -0000 This is a multi-part message in MIME format. --------------040903030609010805070308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/12/10 21:31, Jan 12, Brian Lindsay wrote: > Hi, > Comments inline below.... > > ------------------------------------------------------------------------ > *From:* Adam Roach [mailto:adam@nostrum.com] > ** > Given the context of what has been discussed so far, what you say here > is too vague for me to figure out whether it is correct. When you say > "the domain associated with the SIP PBX," do you mean: > > 1. A domain that doesn't exist in a domain name registry anywhere > 2. A domain that, while properly registered with a domain name > registry, does not exist in DNS > 3. A domain that exists in the global DNS, and which routes to the > SSP if someone applies 3263 procedures > 4. A domain that exists in the global DNS, and which routes to the > PBX if someone applies 3263 procedures > > [Lindsay, Brian] More than one of these might be possible, but I was > basically refering to the principle illustrated in David's "Flow-2" in > the following post from last week: > http://www.ietf.org/mail-archive/web/martini/current/msg00166.html In that message, Flow-2 is very ambiguous with regards to the relationship between "pbx1.sp.com" and DNS. Are there any DNS records that point to "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 rules? /a --------------040903030609010805070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:
Hi,
 
   Comments inline below....

From: Adam Roach [mailto:adam@nostrum.com]

Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean:
  1. A domain that doesn't exist in a domain name registry anywhere
  2. A domain that, while properly registered with a domain name registry, does not exist in DNS
  3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures
  4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures
[Lindsay, Brian]  More than one of these might be possible, but I was basically refering to the principle illustrated in David's "Flow-2" in the following post from last week:
 

In that message, Flow-2 is very ambiguous with regards to the relationship between "pbx1.sp.com" and DNS. Are there any DNS records that point to "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 rules?

/a
--------------040903030609010805070308-- From adam@nostrum.com Wed Jan 13 08:54:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443763A67D8 for ; Wed, 13 Jan 2010 08:54:07 -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, 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 c9iLXLDYVErQ for ; Wed, 13 Jan 2010 08:54:06 -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 2A87C3A6828 for ; Wed, 13 Jan 2010 08:54:05 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0DGs11k033729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 10:54:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4DFAA9.5000205@nostrum.com> Date: Wed, 13 Jan 2010 10:54:01 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060704060702060009040007" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Draft of MARTINI Virtual Interim I Minutes X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:54:07 -0000 This is a multi-part message in MIME format. --------------060704060702060009040007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This exchange isn't quite was was said: > Hadriel Kaplan: Can you really do this with just a BCP? > Adam Roach: Yes, for what is in the draft, but perhaps not if you need to go beyond that, e.g., for outbound, path. > What I said was that what was on the slide could be done with a BCP. Other mechanisms actually in the draft -- such as the new reg event body -- are protocol extensions. /a --------------060704060702060009040007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This exchange isn't quite was was said:

Hadriel Kaplan: Can you really do this with just a BCP?
Adam Roach: Yes, for what is in the draft, but perhaps not if you need to go beyond that, e.g., for outbound, path.

What I said was that what was on the slide could be done with a BCP. Other mechanisms actually in the draft -- such as the new reg event body -- are protocol extensions.

/a
--------------060704060702060009040007-- From spencer@wonderhamster.org Wed Jan 13 09:49:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380693A6A18 for ; Wed, 13 Jan 2010 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 hJYkk69NJdKC for ; Wed, 13 Jan 2010 09:49:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id EB1663A6A14 for ; Wed, 13 Jan 2010 09:49:54 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MPDNg-1NZXC52Muu-004asl; Wed, 13 Jan 2010 12:49:51 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" , "Brian Lindsay" References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> Date: Wed, 13 Jan 2010 11:49:26 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_33BF_01CA9446.7514CF00" 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+E3ylkdKfL6/n7jePuqHqjdLWxZ1nWnK/MzAc saNDHzHpKbNjfw7oAhGm59l+3uCFhrBXx6MCe1xdEls2FGQGBn y2MxDu4vJGj2ruX8Ul8zAVweF36jCm3p+oYHniVC0c= Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:49:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_33BF_01CA9446.7514CF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adam,=20 I might have misunderstood, but I thought that the point was that the = DNS records would point to the service provider, not directly to the = SIP-PBX. If you have DNS records that point directly to the SIP-PBX, I = don't know how you can NOT do 3263 (the caller gets the DNS results and = decides to send the call to someplace else, based on ??? :-) Ignoring policy, of course, but if the caller has policy at that level, = you don't need 3263 OR any of the bulk registration mechanisms we've = been talking about (and I'm pretty sure you don't need REGISTER, either = :-). Spencer ----- Original Message -----=20 From: Adam Roach=20 To: Brian Lindsay=20 Cc: martini@ietf.org ; Hadriel Kaplan=20 Sent: Wednesday, January 13, 2010 7:47 AM Subject: Re: [martini] draft-roach-martini-up-00 On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:=20 Hi, Comments inline below.... -------------------------------------------------------------------------= --- From: Adam Roach [mailto:adam@nostrum.com]=20 Given the context of what has been discussed so far, what you say = here is too vague for me to figure out whether it is correct. When you = say "the domain associated with the SIP PBX," do you mean: 1.. A domain that doesn't exist in a domain name registry anywhere 2.. A domain that, while properly registered with a domain name = registry, does not exist in DNS=20 3.. A domain that exists in the global DNS, and which routes to = the SSP if someone applies 3263 procedures 4.. A domain that exists in the global DNS, and which routes to = the PBX if someone applies 3263 procedures=20 [Lindsay, Brian] More than one of these might be possible, but I = was basically refering to the principle illustrated in David's "Flow-2" = in the following post from last week: http://www.ietf.org/mail-archive/web/martini/current/msg00166.html In that message, Flow-2 is very ambiguous with regards to the = relationship between "pbx1.sp.com" and DNS. Are there any DNS records = that point to "pbx1.sp.com?" If so, where do they resolve? The PBX = itself? And, if they *do* point to the PBX, why can't the SP just apply = normal 3263 rules? /a -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_33BF_01CA9446.7514CF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Adam,
 
I might have misunderstood, but I thought that the = point was=20 that the DNS records would point to the service provider, not directly = to the=20 SIP-PBX. If you have DNS records that point directly to the SIP-PBX, I = don't=20 know how you can NOT do 3263 (the caller gets the DNS results and = decides to=20 send the call to someplace else, based on ??? :-)
 
Ignoring policy, of course, but if the caller = has policy=20 at that level, you don't need 3263 OR any of the bulk registration = mechanisms=20 we've been talking about (and I'm pretty sure you don't need REGISTER, = either=20 :-).
 
Spencer
----- Original Message -----
From:=20 Adam = Roach
Cc: martini@ietf.org ; Hadriel=20 Kaplan
Sent: Wednesday, January 13, = 2010 7:47=20 AM
Subject: Re: [martini]=20 draft-roach-martini-up-00

On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:=20
Hi,
 
   Comments inline = below....

From: Adam Roach [mailto:adam@nostrum.com]=20

Given the context of what has been = discussed so=20 far, what you say here is too vague for me to figure out whether it = is=20 correct. When you say "the domain associated with the SIP PBX," do = you=20 mean:
  1. A domain that doesn't exist in a domain name registry = anywhere
  2. A domain that, while properly registered with a domain name = registry,=20 does not exist in DNS=20
  3. A domain that exists in the global DNS, and which routes to = the SSP if=20 someone applies 3263 procedures
  4. A domain that exists in the global DNS, and which routes to = the PBX if=20 someone applies 3263 procedures
[Lindsay, Brian]  More than one of these might be = possible,=20 but I was basically refering to the principle illustrated in David's = "Flow-2" in the following post from last week:
 
http://www.ietf.org/mail-archive/web/martini/cur= rent/msg00166.html

In=20 that message, Flow-2 is very ambiguous with regards to the = relationship=20 between "pbx1.sp.com" and DNS. Are there any DNS records that point to = "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if = they *do*=20 point to the PBX, why can't the SP just apply normal 3263 = rules?

/a

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_33BF_01CA9446.7514CF00-- From adam@nostrum.com Wed Jan 13 13:18:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FF43A683C for ; Wed, 13 Jan 2010 13:18:38 -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, 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 G3LW2snfPC71 for ; Wed, 13 Jan 2010 13:18: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 105A63A6828 for ; Wed, 13 Jan 2010 13:18:35 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0DLIN5L054470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 15:18:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4E389E.50308@nostrum.com> Date: Wed, 13 Jan 2010 15:18:22 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Spencer Dawkins References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020507030902050700090808" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 21:18:38 -0000 This is a multi-part message in MIME format. --------------020507030902050700090808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/13/10 11:49 AM, Spencer Dawkins wrote: > Adam, > I might have misunderstood, but I thought that the point was that the > DNS records would point to the service provider, not directly to the > SIP-PBX. That leads to the looping problem we've discussed a number of times. > If you have DNS records that point directly to the SIP-PBX, I don't > know how you can NOT do 3263 (the caller gets the DNS results and > decides to send the call to someplace else, based on ??? :-) > Ignoring policy, of course, but if the caller has policy at that > level, you don't need 3263 OR any of the bulk registration mechanisms > we've been talking about (and I'm pretty sure you don't need REGISTER, > either :-). Exactly. If 3263 takes you there, then we're done. Shut down MARTINI, the problem has been solved. ;-) Here's the thing -- each of the 4 approaches I mentioned has serious flaws with it. And without nailing down which one people think they're talking about (and I think various people are talking about different things), then I don't think we can come to agreement on how we can address these flaws. So far, people seem to be intentionally evasive about what they actually mean when they talk about how this URL gets rewritten, and what it gets rewritten into. With the URL rewriting rules being proposed, exactly one of the following four properties must be true regarding the domain in the URL; it is either: 1. A domain that doesn't exist in a domain name registry anywhere, 2. A domain that, while properly registered with a domain name registry, does not exist in DNS, 3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures, or 4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures. If I've missed out a valid permutation somewhere, we should introduce it into the equation. But, with these four approaches, there is at _least_ one relatively major hurdle to clear: Approach number 1 leads to potential domain name collisions. It probably won't clear the IESG. Approach number 2 raises the "alternate root" specter we discussed on the call. Approach number 3 has a problem with creating routing loops. Approach number 4 makes the entire MARTINI effort unnecessary. Some of these problems are bigger than others, and most of them (except number 3) are political in nature. It would be good to know which set of problems we're taking on. But until we can get people to explain what they mean by "3263-like handling," we're kind of poking at shadows. Alternately, the whole mess goes away if we use normal proxy/registrar behavior for request routing, and associate a different contact with each of the extensions on the PBX. My draft shows one way this can be done. There are certainly others. /a > Spencer > > ----- Original Message ----- > *From:* Adam Roach > *To:* Brian Lindsay > *Cc:* martini@ietf.org ; Hadriel Kaplan > > *Sent:* Wednesday, January 13, 2010 7:47 AM > *Subject:* Re: [martini] draft-roach-martini-up-00 > > On 1/12/10 21:31, Jan 12, Brian Lindsay wrote: >> Hi, >> Comments inline below.... >> >> ------------------------------------------------------------------------ >> *From:* Adam Roach [mailto:adam@nostrum.com] >> >> Given the context of what has been discussed so far, what you say >> here is too vague for me to figure out whether it is correct. >> When you say "the domain associated with the SIP PBX," do you >> mean:[Lindsay, Brian] More than one of these might be possible, >> but I was basically refering to the principle illustrated in >> David's "Flow-2" in the following post from last week: >> http://www.ietf.org/mail-archive/web/martini/current/msg00166.html > > In that message, Flow-2 is very ambiguous with regards to the > relationship between "pbx1.sp.com" and DNS. Are there any DNS > records that point to "pbx1.sp.com?" If so, where do they resolve? > The PBX itself? And, if they *do* point to the PBX, why can't the > SP just apply normal 3263 rules? > > /a > > ------------------------------------------------------------------------ > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --------------020507030902050700090808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/13/10 11:49 AM, Spencer Dawkins wrote:
Adam,
 
I might have misunderstood, but I thought that the point was that the DNS records would point to the service provider, not directly to the SIP-PBX.

That leads to the looping problem we've discussed a number of times.

If you have DNS records that point directly to the SIP-PBX, I don't know how you can NOT do 3263 (the caller gets the DNS results and decides to send the call to someplace else, based on ??? :-)
 
Ignoring policy, of course, but if the caller has policy at that level, you don't need 3263 OR any of the bulk registration mechanisms we've been talking about (and I'm pretty sure you don't need REGISTER, either :-).

Exactly. If 3263 takes you there, then we're done. Shut down MARTINI, the problem has been solved. ;-)

Here's the thing -- each of the 4 approaches I mentioned has serious flaws with it. And without nailing down which one people think they're talking about (and I think various people are talking about different things), then I don't think we can come to agreement on how we can address these flaws. So far, people seem to be intentionally evasive about what they actually mean when they talk about how this URL gets rewritten, and what it gets rewritten into.

With the URL rewriting rules being proposed, exactly one of the following four properties must be true regarding the domain in the URL; it is either:

  1. A domain that doesn't exist in a domain name registry anywhere,
  2. A domain that, while properly registered with a domain name registry, does not exist in DNS,
  3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures, or
  4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures.

If I've missed out a valid permutation somewhere, we should introduce it into the equation. But, with these four approaches, there is at _least_ one relatively major hurdle to clear:

Approach number 1 leads to potential domain name collisions. It probably won't clear the IESG.

Approach number 2 raises the "alternate root" specter we discussed on the call.

Approach number 3 has a problem with creating routing loops.

Approach number 4 makes the entire MARTINI effort unnecessary.

Some of these problems are bigger than others, and most of them (except number 3) are political in nature. It would be good to know which set of problems we're taking on. But until we can get people to explain what they mean by "3263-like handling," we're kind of poking at shadows.

Alternately, the whole mess goes away if we use normal proxy/registrar behavior for request routing, and associate a different contact with each of the extensions on the PBX. My draft shows one way this can be done. There are certainly others.

/a

 
Spencer
----- Original Message -----
From: Adam Roach
Sent: Wednesday, January 13, 2010 7:47 AM
Subject: Re: [martini] draft-roach-martini-up-00

On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:
Hi,
 
   Comments inline below....

From: Adam Roach [mailto:adam@nostrum.com]

Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean:[Lindsay, Brian]  More than one of these might be possible, but I was basically refering to the principle illustrated in David's "Flow-2" in the following post from last week:
 

In that message, Flow-2 is very ambiguous with regards to the relationship between "pbx1.sp.com" and DNS. Are there any DNS records that point to "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 rules?

/a

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

--------------020507030902050700090808-- From john.elwell@siemens-enterprise.com Thu Jan 14 01:48:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9302A3A68F6 for ; Thu, 14 Jan 2010 01:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 jZ8ZwpHkoiPI for ; Thu, 14 Jan 2010 01:48:54 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D886A3A686A for ; Thu, 14 Jan 2010 01:48:53 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-534104; Thu, 14 Jan 2010 10:48:39 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 138E51EB8293; Thu, 14 Jan 2010 10:48:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 14 Jan 2010 10:48:39 +0100 From: "Elwell, John" To: Adam Roach , Spencer Dawkins Date: Thu, 14 Jan 2010 10:48:37 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqUlfqj1fNrzhC4T56b1sGsDvQ+HAAZux0Q Message-ID: References: <4B44B489.6080708@nostrum.com><4B454064.4000107@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> <4B4E389E.50308@nostrum.com> In-Reply-To: <4B4E389E.50308@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 09:48:55 -0000 Adam, What I have in mind is approach 3. Anyone outside the PBX's domain could do= a DNS look-up, and it would get to the SP, which would then get it to the = PBX. Within the PBX, policy would override the DNS look-up, such that the = PBX would regard itself as responsible for the domain. Concerning approach 1, I can accept your view. Concerning approach 2, I did not fully grasp the "alternate root" concept d= iscussed in the call, and there is nothing in the minutes (I was one of the= note-takers, but I got left behind at that point). Please explain. Concerning approach 4, reasons are given in the problem-statement draft as = to why this is not feasible, and hence the need for MARTINI. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 13 January 2010 21:18 > To: Spencer Dawkins > Cc: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/13/10 11:49 AM, Spencer Dawkins wrote:=20 >=20 > Adam,=20 > =20 > I might have misunderstood, but I thought that the=20 > point was that the DNS records would point to the service=20 > provider, not directly to the SIP-PBX. >=20 >=20 > That leads to the looping problem we've discussed a number of times. >=20 >=20 >=20 > If you have DNS records that point directly to the=20 > SIP-PBX, I don't know how you can NOT do 3263 (the caller=20 > gets the DNS results and decides to send the call to=20 > someplace else, based on ??? :-) > =20 > Ignoring policy, of course, but if the caller has=20 > policy at that level, you don't need 3263 OR any of the bulk=20 > registration mechanisms we've been talking about (and I'm=20 > pretty sure you don't need REGISTER, either :-). >=20 >=20 > Exactly. If 3263 takes you there, then we're done. Shut down=20 > MARTINI, the problem has been solved. ;-) >=20 > Here's the thing -- each of the 4 approaches I mentioned has=20 > serious flaws with it. And without nailing down which one=20 > people think they're talking about (and I think various=20 > people are talking about different things), then I don't=20 > think we can come to agreement on how we can address these=20 > flaws. So far, people seem to be intentionally evasive about=20 > what they actually mean when they talk about how this URL=20 > gets rewritten, and what it gets rewritten into. >=20 > With the URL rewriting rules being proposed, exactly one of=20 > the following four properties must be true regarding the=20 > domain in the URL; it is either: >=20 >=20 >=20 > 1. A domain that doesn't exist in a domain name registry anywhere, > =09 > 2. A domain that, while properly registered with a domain=20 > name registry, does not exist in DNS,=20 > 3. A domain that exists in the global DNS, and which=20 > routes to the SSP if someone applies 3263 procedures, or > =09 > 4. A domain that exists in the global DNS, and which=20 > routes to the PBX if someone applies 3263 procedures.=20 >=20 >=20 > If I've missed out a valid permutation somewhere, we should=20 > introduce it into the equation. But, with these four=20 > approaches, there is at _least_ one relatively major hurdle to clear: >=20 > Approach number 1 leads to potential domain name collisions.=20 > It probably won't clear the IESG. >=20 > Approach number 2 raises the "alternate root" specter we=20 > discussed on the call. >=20 > Approach number 3 has a problem with creating routing loops. >=20 > Approach number 4 makes the entire MARTINI effort unnecessary. >=20 > Some of these problems are bigger than others, and most of=20 > them (except number 3) are political in nature. It would be=20 > good to know which set of problems we're taking on. But until=20 > we can get people to explain what they mean by "3263-like=20 > handling," we're kind of poking at shadows. >=20 > Alternately, the whole mess goes away if we use normal=20 > proxy/registrar behavior for request routing, and associate a=20 > different contact with each of the extensions on the PBX. My=20 > draft shows one way this can be done. There are certainly others. >=20 > /a >=20 >=20 >=20 > =20 > Spencer >=20 > ----- Original Message -----=20 > From: Adam Roach =20 > To: Brian Lindsay =20 > Cc: martini@ietf.org ; Hadriel Kaplan=20 > =20 > Sent: Wednesday, January 13, 2010 7:47 AM > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:=20 >=20 > Hi, > =20 > Comments inline below.... >=20 > ________________________________ >=20 > From: Adam Roach [mailto:adam@nostrum.com]=20 > =09 > =09 > Given the context of what has been=20 > discussed so far, what you say here is too vague for me to=20 > figure out whether it is correct. When you say "the domain=20 > associated with the SIP PBX," do you mean:[Lindsay, Brian] =20 > More than one of these might be possible, but I was basically=20 > refering to the principle illustrated in David's "Flow-2" in=20 > the following post from last week:=20 > =20 > =09 > http://www.ietf.org/mail-archive/web/martini/current/msg00166.html >=20 >=20 > In that message, Flow-2 is very ambiguous with=20 > regards to the relationship between "pbx1.sp.com" and DNS.=20 > Are there any DNS records that point to "pbx1.sp.com?" If so,=20 > where do they resolve? The PBX itself? And, if they *do*=20 > point to the PBX, why can't the SP just apply normal 3263 rules? > =09 > /a > =09 >=20 > ________________________________ >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > =09 >=20 >=20 > = From adam@nostrum.com Thu Jan 14 07:50:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F203A67DB for ; Thu, 14 Jan 2010 07:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sh4eHo+989U for ; Thu, 14 Jan 2010 07:50:18 -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 3E8533A6403 for ; Thu, 14 Jan 2010 07:50:17 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0EFoBmM042726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 09:50:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4F3D33.1040708@nostrum.com> Date: Thu, 14 Jan 2010 09:50:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> <4B4E389E.50308@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:50:20 -0000 On 1/14/10 03:48, Jan 14, Elwell, John wrote: > What I have in mind is approach 3. Anyone outside the PBX's domain could do a DNS look-up, and it would get to the SP, which would then get it to the PBX. Within the PBX, policy would override the DNS look-up, such that the PBX would regard itself as responsible for the domain. > Unless it doesn't, and then you've got a loop. What's being designed here is a perfect storm of bad decisions. There is a contingent of people who think we don't need an explicit indicator for these procedures. Combined with approach #3, this leads to situations in which non-MARTINI UAs register at the SSP; the SSP invokes MARTINI procedures (without an indicator, how would he know not to?); and then any incoming calls end up looping. Even without that, the lack of an explicit list of domains that the PBX is claiming authority for leads to a very, very easy mis-provisioning in which the SSP thinks the PBX should handle a specific domain, but the PBX doesn't think it should. Looping again. > Concerning approach 2, I did not fully grasp the "alternate root" concept discussed in the call, and there is nothing in the minutes (I was one of the note-takers, but I got left behind at that point). Please explain. > Both approaches 2 and 3 suffer from this issue, by the way. I just think the technical problems with approach 3 are sufficiently damning that we don't even need to explore the political ramifications. But they're real, and they can torpedo our work late in the process. The general idea is that resolution of domain names to IP addresses is inherently something that must be stable for the Internet to operate correctly. That means that attempts to turn a name into an IP address need to yield the same results no matter who is asking or where they are in the network. To ensure this property, we have a single, unique, unified, and Internet-wide domain name system. It is a single hierarchical tree, with a "single root." Any design for turning names into IP addresses that yields different results than the global DNS runs contrary to this "single root" approach. It is highly likely that members of the IESG and/or IAB are willing to light themselves on fire to prevent any kind of beachhead that can be interpreted as sanctioning of such a design. Concerned members of the IETF community at large are likely to be sufficiently concerned as to file an appeal to attempt block publishing the MARTINI documents as RFCs. In short, it's a political minefield. We're better off choosing a different patch of land for our dance floor. > Concerning approach 4, reasons are given in the problem-statement draft as to why this is not feasible, and hence the need for MARTINI. > I think we're pretty much in agreement on this point. At least, if we accept the stated conditions that led to the formation of MARTINI, then it's clear that approach 4 is not a solution to the problems. /a > John > > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: 13 January 2010 21:18 >> To: Spencer Dawkins >> Cc: Hadriel Kaplan; martini@ietf.org >> Subject: Re: [martini] draft-roach-martini-up-00 >> >> On 1/13/10 11:49 AM, Spencer Dawkins wrote: >> >> Adam, >> >> I might have misunderstood, but I thought that the >> point was that the DNS records would point to the service >> provider, not directly to the SIP-PBX. >> >> >> That leads to the looping problem we've discussed a number of times. >> >> >> >> If you have DNS records that point directly to the >> SIP-PBX, I don't know how you can NOT do 3263 (the caller >> gets the DNS results and decides to send the call to >> someplace else, based on ??? :-) >> >> Ignoring policy, of course, but if the caller has >> policy at that level, you don't need 3263 OR any of the bulk >> registration mechanisms we've been talking about (and I'm >> pretty sure you don't need REGISTER, either :-). >> >> >> Exactly. If 3263 takes you there, then we're done. Shut down >> MARTINI, the problem has been solved. ;-) >> >> Here's the thing -- each of the 4 approaches I mentioned has >> serious flaws with it. And without nailing down which one >> people think they're talking about (and I think various >> people are talking about different things), then I don't >> think we can come to agreement on how we can address these >> flaws. So far, people seem to be intentionally evasive about >> what they actually mean when they talk about how this URL >> gets rewritten, and what it gets rewritten into. >> >> With the URL rewriting rules being proposed, exactly one of >> the following four properties must be true regarding the >> domain in the URL; it is either: >> >> >> >> 1. A domain that doesn't exist in a domain name registry anywhere, >> >> 2. A domain that, while properly registered with a domain >> name registry, does not exist in DNS, >> 3. A domain that exists in the global DNS, and which >> routes to the SSP if someone applies 3263 procedures, or >> >> 4. A domain that exists in the global DNS, and which >> routes to the PBX if someone applies 3263 procedures. >> >> >> If I've missed out a valid permutation somewhere, we should >> introduce it into the equation. But, with these four >> approaches, there is at _least_ one relatively major hurdle to clear: >> >> Approach number 1 leads to potential domain name collisions. >> It probably won't clear the IESG. >> >> Approach number 2 raises the "alternate root" specter we >> discussed on the call. >> >> Approach number 3 has a problem with creating routing loops. >> >> Approach number 4 makes the entire MARTINI effort unnecessary. >> >> Some of these problems are bigger than others, and most of >> them (except number 3) are political in nature. It would be >> good to know which set of problems we're taking on. But until >> we can get people to explain what they mean by "3263-like >> handling," we're kind of poking at shadows. >> >> Alternately, the whole mess goes away if we use normal >> proxy/registrar behavior for request routing, and associate a >> different contact with each of the extensions on the PBX. My >> draft shows one way this can be done. There are certainly others. >> >> /a >> >> >> >> >> Spencer >> >> ----- Original Message ----- >> From: Adam Roach >> To: Brian Lindsay >> Cc: martini@ietf.org ; Hadriel Kaplan >> >> Sent: Wednesday, January 13, 2010 7:47 AM >> Subject: Re: [martini] draft-roach-martini-up-00 >> >> On 1/12/10 21:31, Jan 12, Brian Lindsay wrote: >> >> Hi, >> >> Comments inline below.... >> >> ________________________________ >> >> From: Adam Roach [mailto:adam@nostrum.com] >> >> >> Given the context of what has been >> discussed so far, what you say here is too vague for me to >> figure out whether it is correct. When you say "the domain >> associated with the SIP PBX," do you mean:[Lindsay, Brian] >> More than one of these might be possible, but I was basically >> refering to the principle illustrated in David's "Flow-2" in >> the following post from last week: >> >> >> http://www.ietf.org/mail-archive/web/martini/current/msg00166.html >> >> >> In that message, Flow-2 is very ambiguous with >> regards to the relationship between "pbx1.sp.com" and DNS. >> Are there any DNS records that point to "pbx1.sp.com?" If so, >> where do they resolve? The PBX itself? And, if they *do* >> point to the PBX, why can't the SP just apply normal 3263 rules? >> >> /a >> >> >> ________________________________ >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> >> >> From HKaplan@acmepacket.com Thu Jan 14 09:03:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821273A68F5 for ; Thu, 14 Jan 2010 09:03:01 -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 iE-+S1NGAz3V for ; Thu, 14 Jan 2010 09:03:00 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 81DCD3A67B2 for ; Thu, 14 Jan 2010 09:03:00 -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, 14 Jan 2010 12:02:57 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 14 Jan 2010 12:02:56 -0500 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" , "Elwell, John" , "martini@ietf.org" Date: Thu, 14 Jan 2010 12:02:56 -0500 Thread-Topic: Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQBBWjVAAR/nzJA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 17:03:01 -0000 I think you guys are talking past each other, or maybe are actually in vehe= ment agreement without realizing it. Imagine we have SSP-A and SSP-B. In a 3263 peering relationship, if SSP-A gets a request for sip:user@SSP-B.= com, it won't change the request-uri, and there will NOT be a loop, because= the RURI's domain is *SSP-B*. IF SSP-A gets a request for sip:user@SSP-A.com, and it sends it to SSP-B, i= t must *retarget* the request, BEFORE applying 3263 procedures. Thus it WI= LL replace the RURI, with at least SSP-B.com. So in this Registration-based mechanism we ARE talking about doing the same= thing as 3263 procedures. -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: Friday, January 08, 2010 6:39 PM > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > I would like to see a SHOULD on something like: >=20 > The mechansism should allow handling of inbound requests and outbound > requests between SSP and PBX to be as common as possible as for a normal > peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned= . > The handing of requests at the incoming / outgoing gateway in the edge PB= X > should be common once the mechanism has been applied. >=20 > Essentially this means that the Request-URI should not be replaced by the > SSP on requests sent to the PBX. >=20 > regards >=20 > Keith >=20 From adam@nostrum.com Thu Jan 14 09:19:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3F13A681F for ; Thu, 14 Jan 2010 09:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XxTBulhwSNh for ; Thu, 14 Jan 2010 09:19:26 -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 BAE5F3A63D3 for ; Thu, 14 Jan 2010 09:19:25 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0EHJ87i020575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 11:19:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B4F520C.9000208@nostrum.com> Date: Thu, 14 Jan 2010 11:19:08 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 17:19:27 -0000 On 1/14/10 11:02, Jan 14, Hadriel Kaplan wrote: > I think you guys are talking past each other, or maybe are actually in vehement agreement without realizing it. > > Imagine we have SSP-A and SSP-B. > > In a 3263 peering relationship, if SSP-A gets a request for sip:user@SSP-B.com, it won't change the request-uri, and there will NOT be a loop, because the RURI's domain is *SSP-B*. > And, far more importantly, applying DNS to SSP-B returns an IP address belonging to one of SSP-B's servers. *That* is why it won't loop. > IF SSP-A gets a request for sip:user@SSP-A.com, and it sends it to SSP-B, it must *retarget* the request, BEFORE applying 3263 procedures. Thus it WILL replace the RURI, with at least SSP-B.com. > > So in this Registration-based mechanism we ARE talking about doing the same thing as 3263 procedures. > The problem is that Keith is using phrases like "the Request-URI should not be replaced by the SSP on requests sent to the PBX." Let's step through the ramifications of that statement. It had to arrive at the SSP somehow, right? How did it get there? The only plausible answer is that the Request URI that arrived at the SSP contains a domain that, when fed into DNS, returns an IP address pointing to a server at the SSP. Now, let's apply Keith's assertion that this URI "should not be replaced." This means that the request will arrive at the PBX with a RURI that points back to a machine at the SSP. In your example, this would be equivalent to SSP-A getting a request for "sip:user@SSP-A.com" and forwarding it to SSP-B *WITHOUT* *CHANGING* *THE* *REQUEST* *URI*. You and I can see that this is a fantastically bad idea. In fact, it's so mind-numbingly obvious to you that you apparently can't bring yourself to believe that this is exactly what Keith and John are lobbying for. But read their words carefully. /a > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of DRAGE, Keith (Keith) >> Sent: Friday, January 08, 2010 6:39 PM >> To: Elwell, John; martini@ietf.org >> Subject: Re: [martini] Requirements - rev1 >> >> I would like to see a SHOULD on something like: >> >> The mechansism should allow handling of inbound requests and outbound >> requests between SSP and PBX to be as common as possible as for a normal >> peering arrangement (e.g. RFC 3263 based), as far as the PBX is concerned. >> The handing of requests at the incoming / outgoing gateway in the edge PBX >> should be common once the mechanism has been applied. >> >> Essentially this means that the Request-URI should not be replaced by the >> SSP on requests sent to the PBX. >> >> regards >> >> Keith >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From john.elwell@siemens-enterprise.com Thu Jan 14 12:25:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13DA3A67E7 for ; Thu, 14 Jan 2010 12:25:18 -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 6ejwPJrlZhr1 for ; Thu, 14 Jan 2010 12:25:17 -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 0FE4C3A6405 for ; Thu, 14 Jan 2010 12:25:13 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-544263; Thu, 14 Jan 2010 21:25:08 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6EA801EB8293; Thu, 14 Jan 2010 21:25:08 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jan 2010 21:25:08 +0100 From: "Elwell, John" To: Adam Roach Date: Thu, 14 Jan 2010 21:25:06 +0100 Thread-Topic: [martini] draft-roach-martini-up-00 Thread-Index: AcqVMUfMXqrj9Q9kSnSL2cCtCkbV8QAJYwfg Message-ID: References: <4B44B489.6080708@nostrum.com><4B45F429.3080802@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> <4B4E389E.50308@nostrum.com> <4B4F3D33.1040708@nostrum.com> In-Reply-To: <4B4F3D33.1040708@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 20:25:18 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 14 January 2010 15:50 > To: Elwell, John > Cc: Spencer Dawkins; Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] draft-roach-martini-up-00 >=20 > On 1/14/10 03:48, Jan 14, Elwell, John wrote: > > What I have in mind is approach 3. Anyone outside the PBX's=20 > domain could do a DNS look-up, and it would get to the SP,=20 > which would then get it to the PBX. Within the PBX, policy=20 > would override the DNS look-up, such that the PBX would=20 > regard itself as responsible for the domain. > > =20 >=20 > Unless it doesn't, and then you've got a loop. What's being designed=20 > here is a perfect storm of bad decisions. >=20 > There is a contingent of people who think we don't need an explicit=20 > indicator for these procedures. Combined with approach #3,=20 > this leads to=20 > situations in which non-MARTINI UAs register at the SSP; the=20 > SSP invokes=20 > MARTINI procedures (without an indicator, how would he know not to?);=20 > and then any incoming calls end up looping. [JRE] The shaken draft includes an explicit indicator. >=20 > Even without that, the lack of an explicit list of domains=20 > that the PBX=20 > is claiming authority for leads to a very, very easy=20 > mis-provisioning in=20 > which the SSP thinks the PBX should handle a specific domain, but the=20 > PBX doesn't think it should. Looping again. [JRE] Yes, this doesn't entirely get around the provisioning problem, but I= think that is outside the scope of MARTINI. >=20 >=20 > > Concerning approach 2, I did not fully grasp the "alternate=20 > root" concept discussed in the call, and there is nothing in=20 > the minutes (I was one of the note-takers, but I got left=20 > behind at that point). Please explain. > > =20 >=20 > Both approaches 2 and 3 suffer from this issue, by the way. I=20 > just think=20 > the technical problems with approach 3 are sufficiently=20 > damning that we=20 > don't even need to explore the political ramifications. But they're=20 > real, and they can torpedo our work late in the process. >=20 > The general idea is that resolution of domain names to IP=20 > addresses is=20 > inherently something that must be stable for the Internet to operate=20 > correctly. That means that attempts to turn a name into an IP address=20 > need to yield the same results no matter who is asking or=20 > where they are=20 > in the network. To ensure this property, we have a single, unique,=20 > unified, and Internet-wide domain name system. It is a single=20 > hierarchical tree, with a "single root." >=20 > Any design for turning names into IP addresses that yields different=20 > results than the global DNS runs contrary to this "single root"=20 > approach. It is highly likely that members of the IESG and/or IAB are=20 > willing to light themselves on fire to prevent any kind of beachhead=20 > that can be interpreted as sanctioning of such a design. Concerned=20 > members of the IETF community at large are likely to be sufficiently=20 > concerned as to file an appeal to attempt block publishing=20 > the MARTINI=20 > documents as RFCs. [JRE] I don't see how option 3 leads to this situation. Anyone looking in t= he DNS for pbx.com will be pointed at the SP. The SP will know it uses MART= INI procedures for pbx.com. The PBX will know it is responsible for pbx.com= . John >=20 > In short, it's a political minefield. We're better off choosing a=20 > different patch of land for our dance floor. >=20 >=20 > > Concerning approach 4, reasons are given in the=20 > problem-statement draft as to why this is not feasible, and=20 > hence the need for MARTINI. > > =20 >=20 > I think we're pretty much in agreement on this point. At least, if we=20 > accept the stated conditions that led to the formation of=20 > MARTINI, then=20 > it's clear that approach 4 is not a solution to the problems. >=20 > /a >=20 > > John > > > > > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > >> Sent: 13 January 2010 21:18 > >> To: Spencer Dawkins > >> Cc: Hadriel Kaplan; martini@ietf.org > >> Subject: Re: [martini] draft-roach-martini-up-00 > >> > >> On 1/13/10 11:49 AM, Spencer Dawkins wrote: > >> > >> Adam, > >> =09 > >> I might have misunderstood, but I thought that the > >> point was that the DNS records would point to the service > >> provider, not directly to the SIP-PBX. > >> > >> > >> That leads to the looping problem we've discussed a number=20 > of times. > >> > >> > >> > >> If you have DNS records that point directly to the > >> SIP-PBX, I don't know how you can NOT do 3263 (the caller > >> gets the DNS results and decides to send the call to > >> someplace else, based on ??? :-) > >> =09 > >> Ignoring policy, of course, but if the caller has > >> policy at that level, you don't need 3263 OR any of the bulk > >> registration mechanisms we've been talking about (and I'm > >> pretty sure you don't need REGISTER, either :-). > >> > >> > >> Exactly. If 3263 takes you there, then we're done. Shut down > >> MARTINI, the problem has been solved. ;-) > >> > >> Here's the thing -- each of the 4 approaches I mentioned has > >> serious flaws with it. And without nailing down which one > >> people think they're talking about (and I think various > >> people are talking about different things), then I don't > >> think we can come to agreement on how we can address these > >> flaws. So far, people seem to be intentionally evasive about > >> what they actually mean when they talk about how this URL > >> gets rewritten, and what it gets rewritten into. > >> > >> With the URL rewriting rules being proposed, exactly one of > >> the following four properties must be true regarding the > >> domain in the URL; it is either: > >> > >> > >> > >> 1. A domain that doesn't exist in a domain name registry anywhere, > >> =09 > >> 2. A domain that, while properly registered with a domain > >> name registry, does not exist in DNS, > >> 3. A domain that exists in the global DNS, and which > >> routes to the SSP if someone applies 3263 procedures, or > >> =09 > >> 4. A domain that exists in the global DNS, and which > >> routes to the PBX if someone applies 3263 procedures. > >> > >> > >> If I've missed out a valid permutation somewhere, we should > >> introduce it into the equation. But, with these four > >> approaches, there is at _least_ one relatively major=20 > hurdle to clear: > >> > >> Approach number 1 leads to potential domain name collisions. > >> It probably won't clear the IESG. > >> > >> Approach number 2 raises the "alternate root" specter we > >> discussed on the call. > >> > >> Approach number 3 has a problem with creating routing loops. > >> > >> Approach number 4 makes the entire MARTINI effort unnecessary. > >> > >> Some of these problems are bigger than others, and most of > >> them (except number 3) are political in nature. It would be > >> good to know which set of problems we're taking on. But until > >> we can get people to explain what they mean by "3263-like > >> handling," we're kind of poking at shadows. > >> > >> Alternately, the whole mess goes away if we use normal > >> proxy/registrar behavior for request routing, and associate a > >> different contact with each of the extensions on the PBX. My > >> draft shows one way this can be done. There are certainly others. > >> > >> /a > >> > >> > >> > >> =09 > >> Spencer > >> > >> ----- Original Message ----- > >> From: Adam Roach > >> To: Brian Lindsay > >> Cc: martini@ietf.org ; Hadriel Kaplan > >> > >> Sent: Wednesday, January 13, 2010 7:47 AM > >> Subject: Re: [martini] draft-roach-martini-up-00 > >> > >> On 1/12/10 21:31, Jan 12, Brian Lindsay wrote: > >> > >> Hi, > >> =09 > >> Comments inline below.... > >> > >> ________________________________ > >> > >> From: Adam Roach [mailto:adam@nostrum.com] > >> =09 > >> =09 > >> Given the context of what has been > >> discussed so far, what you say here is too vague for me to > >> figure out whether it is correct. When you say "the domain > >> associated with the SIP PBX," do you mean:[Lindsay, Brian] > >> More than one of these might be possible, but I was basically > >> refering to the principle illustrated in David's "Flow-2" in > >> the following post from last week: > >> =09 > >> =09 > >> http://www.ietf.org/mail-archive/web/martini/current/msg00166.html > >> > >> > >> In that message, Flow-2 is very ambiguous with > >> regards to the relationship between "pbx1.sp.com" and DNS. > >> Are there any DNS records that point to "pbx1.sp.com?" If so, > >> where do they resolve? The PBX itself? And, if they *do* > >> point to the PBX, why can't the SP just apply normal 3263 rules? > >> =09 > >> /a > >> =09 > >> > >> ________________________________ > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> =09 > >> > >> > >> =20 >=20 > = From john.elwell@siemens-enterprise.com Thu Jan 14 12:26:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485133A6848 for ; Thu, 14 Jan 2010 12:26:43 -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.034, 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 Vo9swQWRy2+s for ; Thu, 14 Jan 2010 12:26:42 -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 0BF373A6805 for ; Thu, 14 Jan 2010 12:26:41 -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-544257; Thu, 14 Jan 2010 21:26:38 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6BDDB1EB8293; Thu, 14 Jan 2010 21:26:38 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 14 Jan 2010 21:26:38 +0100 From: "Elwell, John" To: Adam Roach , Hadriel Kaplan Date: Thu, 14 Jan 2010 21:26:36 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqVPbmSPs600NMZQ/SfsNnKA8LqUgAGHyIg Message-ID: References: <4B4F520C.9000208@nostrum.com> In-Reply-To: <4B4F520C.9000208@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 20:26:43 -0000 =20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 14 January 2010 17:19 > To: Hadriel Kaplan > Cc: DRAGE, Keith (Keith); Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/14/10 11:02, Jan 14, Hadriel Kaplan wrote: > > I think you guys are talking past each other, or maybe are=20 > actually in vehement agreement without realizing it. > > > > Imagine we have SSP-A and SSP-B. > > > > In a 3263 peering relationship, if SSP-A gets a request for=20 > sip:user@SSP-B.com, it won't change the request-uri, and=20 > there will NOT be a loop, because the RURI's domain is *SSP-B*. > > =20 >=20 > And, far more importantly, applying DNS to SSP-B returns an=20 > IP address=20 > belonging to one of SSP-B's servers. *That* is why it won't loop. >=20 > > IF SSP-A gets a request for sip:user@SSP-A.com, and it=20 > sends it to SSP-B, it must *retarget* the request, BEFORE=20 > applying 3263 procedures. Thus it WILL replace the RURI,=20 > with at least SSP-B.com. > > > > So in this Registration-based mechanism we ARE talking=20 > about doing the same thing as 3263 procedures. > > =20 >=20 > The problem is that Keith is using phrases like "the=20 > Request-URI should=20 > not be replaced by the SSP on requests sent to the PBX." >=20 > Let's step through the ramifications of that statement. >=20 > It had to arrive at the SSP somehow, right? How did it get there? >=20 > The only plausible answer is that the Request URI that arrived at the=20 > SSP contains a domain that, when fed into DNS, returns an IP address=20 > pointing to a server at the SSP. >=20 > Now, let's apply Keith's assertion that this URI "should not=20 > be replaced." >=20 > This means that the request will arrive at the PBX with a RURI that=20 > points back to a machine at the SSP. In your example, this would be=20 > equivalent to SSP-A getting a request for "sip:user@SSP-A.com" and=20 > forwarding it to SSP-B *WITHOUT* *CHANGING* *THE* *REQUEST* *URI*. >=20 > You and I can see that this is a fantastically bad idea. In=20 > fact, it's=20 > so mind-numbingly obvious to you that you apparently can't bring=20 > yourself to believe that this is exactly what Keith and John are=20 > lobbying for. [JRE] I am not lobbying for the case where a request to user@ssp.com is pas= sed on by ssp.com to pbx.com. In that case the Request-URI would have to be= changed. However, if a request to user@pbx.com arrives at ssp.com (because= 3263 routing takes it there), in that case it should be passed on unchange= d to user@pbx.com. I can't speak for Keith, but I perhaps that was the case= he was referring to. John >=20 > But read their words carefully. >=20 > /a >=20 >=20 >=20 > > =20 > >> -----Original Message----- > >> From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf > >> Of DRAGE, Keith (Keith) > >> Sent: Friday, January 08, 2010 6:39 PM > >> To: Elwell, John; martini@ietf.org > >> Subject: Re: [martini] Requirements - rev1 > >> > >> I would like to see a SHOULD on something like: > >> > >> The mechansism should allow handling of inbound requests=20 > and outbound > >> requests between SSP and PBX to be as common as possible=20 > as for a normal > >> peering arrangement (e.g. RFC 3263 based), as far as the=20 > PBX is concerned. > >> The handing of requests at the incoming / outgoing gateway=20 > in the edge PBX > >> should be common once the mechanism has been applied. > >> > >> Essentially this means that the Request-URI should not be=20 > replaced by the > >> SSP on requests sent to the PBX. > >> > >> regards > >> > >> Keith > >> > >> =20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > =20 >=20 > = From bernard_aboba@hotmail.com Fri Jan 15 14:13:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D84E3A67E5 for ; Fri, 15 Jan 2010 14:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_05=-1.11, 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 4GvcXOE8BQzt for ; Fri, 15 Jan 2010 14:13:16 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 5C9923A6784 for ; Fri, 15 Jan 2010 14:13:16 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 14:13:13 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 15 Jan 2010 14:13:11 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_051A_01CA95EC.DF22A2D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqWL+0HkKB5Ep6oSqSbEmo4whXYpA== Content-Language: en-us X-OriginalArrivalTime: 15 Jan 2010 22:13:13.0688 (UTC) FILETIME=[EE2A9D80:01CA962F] Subject: [martini] Re-targeting, domain ownership and routing X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 22:13:24 -0000 ------=_NextPart_000_051A_01CA95EC.DF22A2D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Adam Roach said: "each of the 4 approaches I mentioned has serious flaws with it. And without nailing down which one people think they're talking about (and I think various people are talking about different things), then I don't think we can come to agreement on how we can address these flaws." [BA] Getting to the bottom of this seems like an important step to me, so I've created a separate thread for the discussion. In particular, in two other messages, Adam has posed clarifying questions whose answers seem important. Can we focus on those for a bit? 1. Referring to David's flow diagrams (see http://www.ietf.org/mail-archive/web/martini/current/msg00182.html ) Adam Roach said: "David: I think you've represented my concerns accurately below. I still think that Keith is advocating Flow-1. Keith: can you clarify your position? " 2. Also, in another message (http://www.ietf.org/mail-archive/web/martini/current/msg00196.html ), Adam Roach said: "Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean: 1. A domain that doesn't exist in a domain name registry anywhere 2. A domain that, while properly registered with a domain name registry, does not exist in DNS 3. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures 4. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures [Lindsay, Brian] More than one of these might be possible, but I was basically referring to the principle illustrated in David's "Flow-2" in the following post from last week: http://www.ietf.org/mail-archive/web/martini/current/msg00166.html In that message, Flow-2 is very ambiguous with regards to the relationship between "pbx1.sp.com" and DNS. Are there any DNS records that point to "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 rules?" ------=_NextPart_000_051A_01CA95EC.DF22A2D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Adam Roach said:

 

“each of the 4 = approaches I mentioned has serious flaws with it. And without nailing down which one = people think they're talking about (and I think various people are talking = about different things), then I don't think we can come to agreement on how we = can address these flaws.”

 

[BA]  Getting to the bottom of this seems like = an important step to me, so I’ve created a separate thread for the discussion.   

 

In particular, in two other messages, Adam has = posed clarifying questions whose answers seem important.  Can we focus on = those for  a bit?

 

 

 

1.       Referring to David’s flow diagrams (see http://www.ietf.org/mail-archive/web/martini/current/msg00182.html= ) Adam Roach said:

 

“David:

 

I think you've represented my concerns accurately below. I still think = that Keith is advocating Flow-1.

 

Keith: can you clarify your position?

”

 

2.       Also, in another message (http://www.ietf.org/mail-archive/web/martini/current/msg00196.html= ), Adam Roach said:

 

“Given the = context of what has been discussed so far, what you say here is too vague for me to = figure out whether it is correct. When you say "the domain associated with the = SIP PBX," do you mean:

  1. A domain that doesn't exist in a = domain name registry anywhere
  2. A domain that, while properly = registered with a domain name registry, does not exist in DNS
  3. A domain that exists in the global = DNS, and which routes to the SSP if someone applies 3263 = procedures
  4. A domain that exists in the global = DNS, and which routes to the PBX if someone applies 3263 procedures =

[Lindsay, Brian]  More than one of these might be = possible, but I was basically referring to the principle illustrated in David's "Flow-2" in the following post from last week:

 

http://www.ietf.org/mail-archive/web/martini/current/msg00166.html=


In that message, Flow-2 is very ambiguous with regards to the = relationship between "pbx1.sp.com" and DNS. Are there any DNS records that = point to "pbx1.sp.com?" If so, where do they resolve? The PBX = itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 = rules?”

 

 

------=_NextPart_000_051A_01CA95EC.DF22A2D0-- From adam@nostrum.com Sat Jan 16 19:28:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E841A3A683B for ; Sat, 16 Jan 2010 19:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM1MkXXNasZy for ; Sat, 16 Jan 2010 19:28:25 -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 B0C063A6405 for ; Sat, 16 Jan 2010 19:28:24 -0800 (PST) Received: from Orthrus-2.local (S01060026b0f718c5.cg.shawcable.net [68.144.85.66]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0H3SAHV096816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jan 2010 21:28:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5283C4.9080700@nostrum.com> Date: Sat, 16 Jan 2010 21:28:04 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 68.144.85.66 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 03:28:26 -0000 On 1/14/10 2:26 PM, Elwell, John wrote: > However, if a request touser@pbx.com arrives at ssp.com (because 3263 routing takes it there)... > Let me finish that sentence for you. "...then the domain pbx.com belongs to ssp.com." And that's where the problem starts. In your view, in this example, who is responsible for the domain "pbx.com"? /a From john.elwell@siemens-enterprise.com Mon Jan 18 00:26:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701313A693F for ; Mon, 18 Jan 2010 00:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 H2v-ZlRzbBL7 for ; Mon, 18 Jan 2010 00:26:52 -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 2EF7E3A680C for ; Mon, 18 Jan 2010 00:26:51 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-566047; Mon, 18 Jan 2010 09:26:47 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6EE5C1EB82A7; Mon, 18 Jan 2010 09:26:47 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 18 Jan 2010 09:26:47 +0100 From: "Elwell, John" To: Adam Roach Date: Mon, 18 Jan 2010 09:26:46 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqXJSCQCu2aGfnxRHG7V/1/kr7TUgA8fRjQ Message-ID: References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> In-Reply-To: <4B5283C4.9080700@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 08:26:53 -0000 Adam, In that example, the PBX is responsible for pbx.com. However, the SP has a = role in routing calls there. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 17 January 2010 03:28 > To: Elwell, John > Cc: Hadriel Kaplan; DRAGE, Keith (Keith); martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/14/10 2:26 PM, Elwell, John wrote: > > However, if a request touser@pbx.com arrives at ssp.com=20 > (because 3263 routing takes it there)... > > =20 >=20 > Let me finish that sentence for you. >=20 > "...then the domain pbx.com belongs to ssp.com." >=20 > And that's where the problem starts. >=20 > In your view, in this example, who is responsible for the=20 > domain "pbx.com"? >=20 > /a > = From pkyzivat@cisco.com Mon Jan 18 06:22:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230803A68AB for ; Mon, 18 Jan 2010 06:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE7cDScgr8VK for ; Mon, 18 Jan 2010 06:22: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 668323A6866 for ; Mon, 18 Jan 2010 06:22: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: ApoEAM79U0utJV2b/2dsb2JhbADBOJQAhDME X-IronPort-AV: E=Sophos;i="4.49,296,1262563200"; d="scan'208";a="80798260" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2010 14:22:30 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0IEMUTZ001713; Mon, 18 Jan 2010 14:22:30 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:22:30 -0600 Received: from [10.86.250.33] ([10.86.250.33]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 08:22:29 -0600 Message-ID: <4B546EA2.8010000@cisco.com> Date: Mon, 18 Jan 2010 09:22:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2010 14:22:29.0528 (UTC) FILETIME=[AA931180:01CA9849] Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 14:22:41 -0000 Elwell, John wrote: > Adam, > > In that example, the PBX is responsible for pbx.com. However, the SP has a role in routing calls there. You are saying that the DNS lookup for pbx.com resolves to the SSP, but that the pbx, not the SSP, is *responsible* for the domain? This is either broken, or else it is a sort of relationship for which we currently have no definition. It either requires hairpinning through the ssp for calls between pbx devices, or else it requires something akin to a split DNS to avoid that. If this is to be considered valid, then I think some careful specification will be needed to ensure that it will be used in a correct way. Thanks, Paul > John > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 17 January 2010 03:28 >> To: Elwell, John >> Cc: Hadriel Kaplan; DRAGE, Keith (Keith); martini@ietf.org >> Subject: Re: [martini] Requirements - rev1 >> >> On 1/14/10 2:26 PM, Elwell, John wrote: >>> However, if a request touser@pbx.com arrives at ssp.com >> (because 3263 routing takes it there)... >>> >> Let me finish that sentence for you. >> >> "...then the domain pbx.com belongs to ssp.com." >> >> And that's where the problem starts. >> >> In your view, in this example, who is responsible for the >> domain "pbx.com"? >> >> /a >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From dean.willis@softarmor.com Mon Jan 18 10:46:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5BB3A6921 for ; Mon, 18 Jan 2010 10:46:46 -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 N7cu8YEp12DT for ; Mon, 18 Jan 2010 10:46:45 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 12A1F3A67A8 for ; Mon, 18 Jan 2010 10:46:45 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0IIkI3G023223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jan 2010 12:46:38 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B5283C4.9080700@nostrum.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: Mon, 18 Jan 2010 12:46:12 -0600 References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 18:46:46 -0000 On Jan 16, 2010, at 9:28 PM, Adam Roach wrote: > On 1/14/10 2:26 PM, Elwell, John wrote: >> However, if a request touser@pbx.com arrives at ssp.com (because >> 3263 routing takes it there)... >> > > Let me finish that sentence for you. > > "...then the domain pbx.com belongs to ssp.com." > > And that's where the problem starts. > > In your view, in this example, who is responsible for the domain > "pbx.com"? Let's see if I can restate John's position: The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP. From a configuration perspective, the PBX "knows" it is authoritative for "pbx.com". The SSP knows it is a relay for "pbx.com". External parties, relying on RFC 3263 resolution, find the relay at SSP instead of the PBX. Incoming requests arrive at the SSP with a target of "pbx.com", and the SSP routes those requests on to pbx.com unchanged (except for a recorded route). The pbx doesn't bother to do a 3263 lookup, because it is configured to use pbx.com as as local domain. This is a common model of operation for email systems dating to UUCP days. It would have worked on unmodified dynamicsoft proxies from 2003. Where's the confusion? Certainly there is a possibility of a misconfiguration. The SSP could think that the PBX is authoritative for "pbx.com" while the PBX doesn't, and this would cause a loop. It's an evident and obvious misconfiguration. If it hurts, don't do it! From the PBX's point of view, the SSP is just a relay proxy, what we would have called an "outbound proxy" ten years ago (before draft-ietf- sip-outbound changed that). No explicit signaling indicator of this relay behavior appears to be needed; it's just basic RFC 3261 on the wire, augmented by relay policy at SSP and an "outbound proxy" setting at PBX. The real question is how PBX informs SSP of its current route and status. Is it static configuration, REGISTER, or something else? -- Dean From bernarda@microsoft.com Mon Jan 18 13:07:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9AA3A67BD for ; Mon, 18 Jan 2010 13:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7xYXc4zhact for ; Mon, 18 Jan 2010 13:07:23 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1F4503A67E1 for ; Mon, 18 Jan 2010 13:07:23 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 18 Jan 2010 13:07:20 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 18 Jan 2010 13:07:11 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 18 Jan 2010 13:07:10 -0800 From: Bernard Aboba To: "Elwell, John" Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqYSah43/Y61GhlTz6QnSXnlJ/OegAN8HyQ Date: Mon, 18 Jan 2010 21:07:10 +0000 Message-ID: References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> <4B546EA2.8010000@cisco.com> In-Reply-To: <4B546EA2.8010000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Jan 2010 13:30:10 -0800 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:07:24 -0000 Paul said:=20 "You are saying that the DNS lookup for pbx.com resolves to the SSP, but=20 that the pbx, not the SSP, is *responsible* for the domain?" [BA] There are a number of DNS RRs we could be talking about here.=20 For example, there are the A/AAAA RRs; and there are the SRV RRs.=20 They don't necessarily have to point to the same place. For example, The A/AAAA RRs could point to the PBX while the SRV RRs could conceivably point to *both* the PBX and the SP (to provide backup). So I'm not clear precisely what "DNS lookup" is referring to here.=20 Paul said: "If this is to be considered valid, then I think some careful=20 specification will be needed to ensure that it will be used in a correct=20 way." [BA] The question in my mind is whether that "careful specification" needs to occur in MARTINI or not.=20 It seems like this issue also occurs in classic "static mode" deployments=20 as well (where MARTINI mechanisms would presumably not be used). In that case, why is this problem specific to MARTINI? From john.elwell@siemens-enterprise.com Mon Jan 18 13:47:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B6D3A67D4 for ; Mon, 18 Jan 2010 13:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 Q1VoDK-v4kQ3 for ; Mon, 18 Jan 2010 13:47:51 -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 D9DDA3A677C for ; Mon, 18 Jan 2010 13:47:50 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-577574; Mon, 18 Jan 2010 22:47:46 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6531023F0278; Mon, 18 Jan 2010 22:47:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 18 Jan 2010 22:47:46 +0100 From: "Elwell, John" To: Bernard Aboba Date: Mon, 18 Jan 2010 22:47:45 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqYSah43/Y61GhlTz6QnSXnlJ/OegAN8HyQAAGX6YA= Message-ID: References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> <4B546EA2.8010000@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 21:47:52 -0000 =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernarda@microsoft.com]=20 > Sent: 18 January 2010 21:07 > To: Elwell, John > Cc: martini@ietf.org > Subject: RE: [martini] Requirements - rev1 >=20 > Paul said:=20 >=20 > "You are saying that the DNS lookup for pbx.com resolves to=20 > the SSP, but=20 > that the pbx, not the SSP, is *responsible* for the domain?" >=20 > [BA] There are a number of DNS RRs we could be talking about here.=20 > For example, there are the A/AAAA RRs; and there are the SRV RRs.=20 >=20 > They don't necessarily have to point to the same place. For example, > The A/AAAA RRs could point to the PBX while the SRV RRs could=20 > conceivably > point to *both* the PBX and the SP (to provide backup). So I'm not > clear precisely what "DNS lookup" is referring to here.=20 >=20 > Paul said: >=20 > "If this is to be considered valid, then I think some careful=20 > specification will be needed to ensure that it will be used=20 > in a correct=20 > way." >=20 > [BA] The question in my mind is whether that "careful specification" > needs to occur in MARTINI or not.=20 >=20 > It seems like this issue also occurs in classic "static mode"=20 > deployments=20 > as well (where MARTINI mechanisms would presumably not be used). In > that case, why is this problem specific to MARTINI? [JRE] Yes, that has been bothering me. I don't see it as something specific= to MARTINI. John > = From bernard_aboba@hotmail.com Mon Jan 18 14:25:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662143A67B7 for ; Mon, 18 Jan 2010 14:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 5JfPf8nzZzDa for ; Mon, 18 Jan 2010 14:25:26 -0800 (PST) Received: from blu0-omc2-s38.blu0.hotmail.com (blu0-omc2-s38.blu0.hotmail.com [65.55.111.113]) by core3.amsl.com (Postfix) with ESMTP id 4DDB03A63D3 for ; Mon, 18 Jan 2010 14:25:26 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 14:25:22 -0800 X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> <4B546EA2.8010000@cisco.com> In-Reply-To: Date: Mon, 18 Jan 2010 14:25:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQMmxEut9XUNVoWO0yHWnOZz8xtH6gFZiW66AGKDacwCosuGAAILVkJKApPyH4ICSxU5zgGjXT/dAUv02qABp9pmoQ== Content-Language: en-us X-OriginalArrivalTime: 18 Jan 2010 22:25:22.0296 (UTC) FILETIME=[1FB09F80:01CA988D] Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:25:27 -0000 Paul said: "You are saying that the DNS lookup for pbx.com resolves to the SSP, but that the pbx, not the SSP, is *responsible* for the domain?" [BA] There are a number of DNS RRs we could be talking about here. For example, there are the A/AAAA RRs; and there are the SRV RRs (and maybe NAPTR RRs). They don't necessarily have to point to the same place. For example, The A/AAAA RRs could point to the PBX while the SRV/NAPTR RRs could conceivably point to *both* the PBX and the SP (to provide backup). So I'm not clear precisely what "DNS lookup" is referring to here. Paul said: "If this is to be considered valid, then I think some careful specification will be needed to ensure that it will be used in a correct way." [BA] The question in my mind is whether that "careful specification" needs to occur in MARTINI or not. It seems like this issue also occurs in classic "static mode" deployments as well (where MARTINI mechanisms would presumably not be used). In that case, why is this problem specific to MARTINI? From pkyzivat@cisco.com Mon Jan 18 14:44:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB2B3A68D4 for ; Mon, 18 Jan 2010 14:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8owXo9aqcU9x for ; Mon, 18 Jan 2010 14:44:58 -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 70F1C3A63D3 for ; Mon, 18 Jan 2010 14:44:57 -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: ApoEADpzVEutJV2Y/2dsb2JhbADBFJQ9hDME X-IronPort-AV: E=Sophos;i="4.49,298,1262563200"; d="scan'208";a="289619135" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2010 22:44:53 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o0IMirsZ029501; Mon, 18 Jan 2010 22:44:53 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 16:44:54 -0600 Received: from [10.86.250.33] ([10.86.250.33]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 16:44:53 -0600 Message-ID: <4B54E463.50406@cisco.com> Date: Mon, 18 Jan 2010 17:44:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bernard Aboba References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> <4B546EA2.8010000@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2010 22:44:53.0432 (UTC) FILETIME=[D9BDCB80:01CA988F] Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:44:59 -0000 Bernard Aboba wrote: > Paul said: > > "You are saying that the DNS lookup for pbx.com resolves to the SSP, but > that the pbx, not the SSP, is *responsible* for the domain?" > > [BA] There are a number of DNS RRs we could be talking about here. > For example, there are the A/AAAA RRs; and there are the SRV RRs. > > They don't necessarily have to point to the same place. For example, > The A/AAAA RRs could point to the PBX while the SRV RRs could conceivably > point to *both* the PBX and the SP (to provide backup). So I'm not > clear precisely what "DNS lookup" is referring to here. Its true that 3261 isn't especially clear about what it means for a server to be responsible for a domain. But to avoid hyjacking, their ought to be *some* relationship between the domain name in the sip URI, the DNS entries for that domain, and the server claiming responsibility. Maybe it shouldn't be specified in Martini, but it ought to be defined *somewhere* in sufficient detail that this can work for Martini. Perhaps we can first figure out what the relationship needs to be, and then decide where it ought to be defined. ISTM that it must be something like: - whoever is responsible for the content of the DNS SIP SRV entry for a domain may designate which servers may claim responsibility for sip requests addressed to URIs containing that domain. I realize that is overly squishy, but I offer it as a starting point. This would allow whoever has the rights to the DNS entries for pbx.com to designate that both the pbx and the appropriate ssp servers may claim responsibility for pbx.com. Beyond that, it seems that this martini approach may be dicing "responsibility" into sub-roles for that domain that are then assigned to the ssp and the pbx. Thanks, Paul > Paul said: > > "If this is to be considered valid, then I think some careful > specification will be needed to ensure that it will be used in a correct > way." > > [BA] The question in my mind is whether that "careful specification" > needs to occur in MARTINI or not. > > It seems like this issue also occurs in classic "static mode" deployments > as well (where MARTINI mechanisms would presumably not be used). In > that case, why is this problem specific to MARTINI? > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From bernard_aboba@hotmail.com Tue Jan 19 08:56:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5958B3A6403 for ; Tue, 19 Jan 2010 08:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.844, 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 BwoqO1XcO17O for ; Tue, 19 Jan 2010 08:55:58 -0800 (PST) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by core3.amsl.com (Postfix) with ESMTP id 132303A689D for ; Tue, 19 Jan 2010 08:55:58 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.71]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jan 2010 08:55:54 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 19 Jan 2010 08:56:26 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CA98E5.48999D40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqZKFZ2EPRO0z9kQuurUeQkJG7TkA== Content-Language: en-us X-OriginalArrivalTime: 19 Jan 2010 16:55:54.0667 (UTC) FILETIME=[43AD8FB0:01CA9928] Subject: [martini] Agenda items for Virtual Interim II X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 16:56:00 -0000 ------=_NextPart_000_0082_01CA98E5.48999D40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit If you'd like time on the Agenda at Virtual Interim II (only 7 days away!), please send email to myself or Spencer ASAP. General topics include: 1. Requirements discussion. 2. Operator perspectives. 3. Solutions. ------=_NextPart_000_0082_01CA98E5.48999D40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

If you’d like time on the Agenda at Virtual = Interim II (only 7 days away!), please send email to myself or Spencer ASAP. =

 

General topics include:

 

1.       Requirements discussion.

2.       Operator perspectives.

3.       Solutions.

------=_NextPart_000_0082_01CA98E5.48999D40-- From john.elwell@siemens-enterprise.com Tue Jan 19 09:57:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5A83A67DF for ; Tue, 19 Jan 2010 09:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 63WisEA5olY0 for ; Tue, 19 Jan 2010 09:57:26 -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 3DCAA3A67A6 for ; Tue, 19 Jan 2010 09:57:22 -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-591337; Tue, 19 Jan 2010 18:57:18 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id F2E311EB82A7; Tue, 19 Jan 2010 18:57:17 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 19 Jan 2010 18:57:17 +0100 From: "Elwell, John" To: Dean Willis , Adam Roach Date: Tue, 19 Jan 2010 18:57:16 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqYbqYSZOhlTA6ZSRW6mvzxuK9LxwAwh+Fw Message-ID: References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> Keywords: MARTINI In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 17:57:27 -0000 Yes, Dean has stated my position better than I did! John=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 18 January 2010 18:46 > To: Adam Roach > Cc: Elwell, John; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 >=20 > On Jan 16, 2010, at 9:28 PM, Adam Roach wrote: >=20 > > On 1/14/10 2:26 PM, Elwell, John wrote: > >> However, if a request touser@pbx.com arrives at ssp.com (because =20 > >> 3263 routing takes it there)... > >> > > > > Let me finish that sentence for you. > > > > "...then the domain pbx.com belongs to ssp.com." > > > > And that's where the problem starts. > > > > In your view, in this example, who is responsible for the domain =20 > > "pbx.com"? >=20 > Let's see if I can restate John's position: >=20 > The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP. >=20 > From a configuration perspective, the PBX "knows" it is=20 > authoritative =20 > for "pbx.com". The SSP knows it is a relay for "pbx.com". External =20 > parties, relying on RFC 3263 resolution, find the relay at=20 > SSP instead =20 > of the PBX. >=20 > Incoming requests arrive at the SSP with a target of "pbx.com", and =20 > the SSP routes those requests on to pbx.com unchanged (except for a =20 > recorded route). The pbx doesn't bother to do a 3263 lookup, because =20 > it is configured to use pbx.com as as local domain. This is a common =20 > model of operation for email systems dating to UUCP days. It would =20 > have worked on unmodified dynamicsoft proxies from 2003. >=20 > Where's the confusion? >=20 > Certainly there is a possibility of a misconfiguration. The=20 > SSP could =20 > think that the PBX is authoritative for "pbx.com" while the PBX =20 > doesn't, and this would cause a loop. It's an evident and obvious =20 > misconfiguration. If it hurts, don't do it! >=20 > From the PBX's point of view, the SSP is just a relay proxy,=20 > what we =20 > would have called an "outbound proxy" ten years ago (before=20 > draft-ietf-=20 > sip-outbound changed that). No explicit signaling indicator of this =20 > relay behavior appears to be needed; it's just basic RFC 3261 on the =20 > wire, augmented by relay policy at SSP and an "outbound=20 > proxy" setting =20 > at PBX. >=20 > The real question is how PBX informs SSP of its current route and =20 > status. Is it static configuration, REGISTER, or something else? >=20 > -- > Dean >=20 > = From spencer@wonderhamster.org Tue Jan 19 12:14:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4E53A6947 for ; Tue, 19 Jan 2010 12:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOGNjGtYv8fn for ; Tue, 19 Jan 2010 12:14:29 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 72FCF3A67A7 for ; Tue, 19 Jan 2010 12:14:29 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MVNH4-1NKmB53n7W-00YsxU; Tue, 19 Jan 2010 15:13:27 -0500 Message-ID: From: "Spencer Dawkins" To: "Dean Willis" , "Adam Roach" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> Date: Tue, 19 Jan 2010 14:13:07 -0600 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+8Kev60ay+CKd0uI+vJjBl8KK0jiRDvRLO21M yF7Q7ej1NMmAR6ROKcfPKyfgxcReH7wpl4wxj2CYkelZAtlLLb n1Q1wCdusskmr9TmiVcduisvHEzuPKVRRlrie0naLw= Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 20:14:31 -0000 I've been looking at Dean's note (below), and wanted to say something out loud that I've been thinking to myself... speaking as an individual, of course. We asked that MARTINI be chartered with a very short timeline for milestones, because we want to use the output of MARTINI in various places like SIPconnect 1.1, and we need that output really badly. Speaking as an individual, I was hoping that we would nail down solution mechanisms in the charter, but we didn't do that, and I'm actually OK with the tone, pace and direction that I've been seeing in discussions about solution mechanisms so far ... ... but I'm very concerned about the idea that MARTINI would need to nail down the details that Dean is describing here, in order to produce a solution specification. I'm not saying that Dean thinks this is necessary, but I am hearing other people talking about whether it's necessary. >From my perspective, we're talking about whether MARTINI is not chartered to solve a problem that isn't MARTINI-specific, has not been previously solved at the IETF (because we've never drawn a "SIP pentazoid" that looks like p --- SP / \ UA PBX \ UA in a way that led the IETF SIP community to describe how the SP-PBX part of this diagram would actually work using RFC 3263), but must be solved so that we can describe how this would actually work in MARTINI mode (which IS MARTINI-specific). If I'm reading Dean's note correctly, he's saying that all this is business-as-usual for RFC 3263 DNS routing, RFC 3261 REGISTER-based routing, and (he didn't say this, but I'm extrapolating) whatever mechanism we end up selecting for MARTINI, so the problem isn't MARTINI-specific, and shouldn't be a MARTINI dependency. Do people disagree with my understanding here? (Especially, but not limited to, Dean?) Because if people disagree, we're tripping over new work that needs to be DISPATCHed, and we're already post-"tell the DISPATCH chairs/working group that a new proposal is coming" for IETF 77. :-( Thanks, Spencer >>> However, if a request touser@pbx.com arrives at ssp.com (because 3263 >>> routing takes it there)... >>> >> >> Let me finish that sentence for you. >> >> "...then the domain pbx.com belongs to ssp.com." >> >> And that's where the problem starts. >> >> In your view, in this example, who is responsible for the domain >> "pbx.com"? > > Let's see if I can restate John's position: > > The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP. > > From a configuration perspective, the PBX "knows" it is authoritative for > "pbx.com". The SSP knows it is a relay for "pbx.com". External parties, > relying on RFC 3263 resolution, find the relay at SSP instead of the PBX. > > Incoming requests arrive at the SSP with a target of "pbx.com", and the > SSP routes those requests on to pbx.com unchanged (except for a recorded > route). The pbx doesn't bother to do a 3263 lookup, because it is > configured to use pbx.com as as local domain. This is a common model of > operation for email systems dating to UUCP days. It would have worked on > unmodified dynamicsoft proxies from 2003. > > Where's the confusion? > > Certainly there is a possibility of a misconfiguration. The SSP could > think that the PBX is authoritative for "pbx.com" while the PBX doesn't, > and this would cause a loop. It's an evident and obvious > misconfiguration. If it hurts, don't do it! > > From the PBX's point of view, the SSP is just a relay proxy, what we > would have called an "outbound proxy" ten years ago (before draft-ietf- > sip-outbound changed that). No explicit signaling indicator of this relay > behavior appears to be needed; it's just basic RFC 3261 on the wire, > augmented by relay policy at SSP and an "outbound proxy" setting at PBX. > > The real question is how PBX informs SSP of its current route and status. > Is it static configuration, REGISTER, or something else? > > -- > Dean > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Tue Jan 19 13:03:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE333A69BD for ; Tue, 19 Jan 2010 13:03:30 -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 2VLZ3333kJJI for ; Tue, 19 Jan 2010 13:03:29 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 06AE93A68F3 for ; Tue, 19 Jan 2010 13:03:28 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-592995; Tue, 19 Jan 2010 22:03:23 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id C9D4B1EB82A7; Tue, 19 Jan 2010 22:03:23 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 19 Jan 2010 22:03:23 +0100 From: "Elwell, John" To: Spencer Dawkins , Dean Willis , Adam Roach Date: Tue, 19 Jan 2010 22:03:21 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqZRAVeCUc4xIBzRqaPDUsSOjOXcgABrjHw Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 21:03:30 -0000 Spencer, I agree with you. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 19 January 2010 20:13 > To: Dean Willis; Adam Roach > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 > I've been looking at Dean's note (below), and wanted to say=20 > something out=20 > loud that I've been thinking to myself... speaking as an=20 > individual, of=20 > course. >=20 > We asked that MARTINI be chartered with a very short timeline for=20 > milestones, because we want to use the output of MARTINI in=20 > various places=20 > like SIPconnect 1.1, and we need that output really badly. >=20 > Speaking as an individual, I was hoping that we would nail=20 > down solution=20 > mechanisms in the charter, but we didn't do that, and I'm=20 > actually OK with=20 > the tone, pace and direction that I've been seeing in=20 > discussions about=20 > solution mechanisms so far ... >=20 > ... but I'm very concerned about the idea that MARTINI would=20 > need to nail=20 > down the details that Dean is describing here, in order to produce a=20 > solution specification. I'm not saying that Dean thinks this=20 > is necessary,=20 > but I am hearing other people talking about whether it's necessary. >=20 > From my perspective, we're talking about whether MARTINI is=20 > not chartered to=20 > solve a problem that isn't MARTINI-specific, has not been=20 > previously solved=20 > at the IETF (because we've never drawn a "SIP pentazoid" that=20 > looks like >=20 > p --- SP > / \ > UA PBX > \ > UA >=20 > in a way that led the IETF SIP community to describe how the=20 > SP-PBX part of=20 > this diagram would actually work using RFC 3263), but must be=20 > solved so that=20 > we can describe > how this would actually work in MARTINI mode (which IS=20 > MARTINI-specific). >=20 > If I'm reading Dean's note correctly, he's saying that all this is=20 > business-as-usual for RFC 3263 DNS routing, RFC 3261=20 > REGISTER-based routing,=20 > and (he didn't say this, but I'm extrapolating) whatever=20 > mechanism we end up=20 > selecting for MARTINI, so the problem isn't MARTINI-specific,=20 > and shouldn't=20 > be a MARTINI dependency. >=20 > Do people disagree with my understanding here? (Especially,=20 > but not limited=20 > to, Dean?) >=20 > Because if people disagree, we're tripping over new work that=20 > needs to be=20 > DISPATCHed, and we're already post-"tell the DISPATCH=20 > chairs/working group=20 > that a new proposal is coming" for IETF 77. :-( >=20 > Thanks, >=20 > Spencer >=20 > >>> However, if a request touser@pbx.com arrives at ssp.com=20 > (because 3263=20 > >>> routing takes it there)... > >>> > >> > >> Let me finish that sentence for you. > >> > >> "...then the domain pbx.com belongs to ssp.com." > >> > >> And that's where the problem starts. > >> > >> In your view, in this example, who is responsible for the domain=20 > >> "pbx.com"? > > > > Let's see if I can restate John's position: > > > > The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP. > > > > From a configuration perspective, the PBX "knows" it is=20 > authoritative for=20 > > "pbx.com". The SSP knows it is a relay for "pbx.com". =20 > External parties,=20 > > relying on RFC 3263 resolution, find the relay at SSP=20 > instead of the PBX. > > > > Incoming requests arrive at the SSP with a target of=20 > "pbx.com", and the=20 > > SSP routes those requests on to pbx.com unchanged (except=20 > for a recorded=20 > > route). The pbx doesn't bother to do a 3263 lookup, because it is=20 > > configured to use pbx.com as as local domain. This is a=20 > common model of=20 > > operation for email systems dating to UUCP days. It would =20 > have worked on=20 > > unmodified dynamicsoft proxies from 2003. > > > > Where's the confusion? > > > > Certainly there is a possibility of a misconfiguration. The=20 > SSP could=20 > > think that the PBX is authoritative for "pbx.com" while the=20 > PBX doesn't,=20 > > and this would cause a loop. It's an evident and obvious=20 > > misconfiguration. If it hurts, don't do it! > > > > From the PBX's point of view, the SSP is just a relay=20 > proxy, what we=20 > > would have called an "outbound proxy" ten years ago (before=20 > draft-ietf-=20 > > sip-outbound changed that). No explicit signaling indicator=20 > of this relay=20 > > behavior appears to be needed; it's just basic RFC 3261 on=20 > the wire,=20 > > augmented by relay policy at SSP and an "outbound proxy"=20 > setting at PBX. > > > > The real question is how PBX informs SSP of its current=20 > route and status.=20 > > Is it static configuration, REGISTER, or something else? > > > > -- > > Dean > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From D.Hancock@CableLabs.com Tue Jan 19 16:22:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E5B3A67F4 for ; Tue, 19 Jan 2010 16:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdM9Xe1jP26D for ; Tue, 19 Jan 2010 16:22:24 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 3F8353A677C for ; Tue, 19 Jan 2010 16:22:24 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id o0K0MDUW012051; Tue, 19 Jan 2010 17:22:17 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 19 Jan 2010 17:22:13 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([::1]) by srvxchg.cablelabs.com ([::1]) with mapi; Tue, 19 Jan 2010 17:22:14 -0700 From: David Hancock To: Spencer Dawkins , Dean Willis , Adam Roach Date: Tue, 19 Jan 2010 17:22:13 -0700 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqZRAJu76xXTBcXRd2NDgCJ3a/VMAAG/otA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD09B4625@srvxchg.cablelabs.com> References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 00:22:26 -0000 Spencer, I agree with your overall summary below. Furthermore, not only does this routing issue exist for the IP-PBX case you= identified... p --- SP / \ UA PBX \ UA ... I think it exists more generally, say to the transit network case.=20 SP(a) --- SP(transit) --- SP(b) / \ / \ UA1 UA2 =20 I'm sure this transit case happens today. How is it being done? It seems this is either...=20 a) a non-issue because it's being handled today in a standards-complaint ma= nner, or b) a real issue (because it's being done in a non-standard way) but is outs= ide the scope of MARTINI (SPEERMINT, perhaps?). Thanks David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Tuesday, January 19, 2010 1:13 PM > To: Dean Willis; Adam Roach > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 > I've been looking at Dean's note (below), and wanted to say something out > loud that I've been thinking to myself... speaking as an individual, of > course. >=20 > We asked that MARTINI be chartered with a very short timeline for > milestones, because we want to use the output of MARTINI in various place= s > like SIPconnect 1.1, and we need that output really badly. >=20 > Speaking as an individual, I was hoping that we would nail down solution > mechanisms in the charter, but we didn't do that, and I'm actually OK wit= h > the tone, pace and direction that I've been seeing in discussions about > solution mechanisms so far ... >=20 > ... but I'm very concerned about the idea that MARTINI would need to nail > down the details that Dean is describing here, in order to produce a > solution specification. I'm not saying that Dean thinks this is necessary= , > but I am hearing other people talking about whether it's necessary. >=20 > From my perspective, we're talking about whether MARTINI is not chartered > to > solve a problem that isn't MARTINI-specific, has not been previously > solved > at the IETF (because we've never drawn a "SIP pentazoid" that looks like >=20 > p --- SP > / \ > UA PBX > \ > UA >=20 > in a way that led the IETF SIP community to describe how the SP-PBX part > of > this diagram would actually work using RFC 3263), but must be solved so > that > we can describe > how this would actually work in MARTINI mode (which IS MARTINI-specific). >=20 > If I'm reading Dean's note correctly, he's saying that all this is > business-as-usual for RFC 3263 DNS routing, RFC 3261 REGISTER-based > routing, > and (he didn't say this, but I'm extrapolating) whatever mechanism we end > up > selecting for MARTINI, so the problem isn't MARTINI-specific, and > shouldn't > be a MARTINI dependency. >=20 > Do people disagree with my understanding here? (Especially, but not > limited > to, Dean?) >=20 > Because if people disagree, we're tripping over new work that needs to be > DISPATCHed, and we're already post-"tell the DISPATCH chairs/working grou= p > that a new proposal is coming" for IETF 77. :-( >=20 > Thanks, >=20 > Spencer >=20 > >>> However, if a request touser@pbx.com arrives at ssp.com (because > 3263 > >>> routing takes it there)... > >>> > >> > >> Let me finish that sentence for you. > >> > >> "...then the domain pbx.com belongs to ssp.com." > >> > >> And that's where the problem starts. > >> > >> In your view, in this example, who is responsible for the domain > >> "pbx.com"? > > > > Let's see if I can restate John's position: > > > > The PBX has delegated RFC 3263 handling for "pbx.com" to the SSP. > > > > From a configuration perspective, the PBX "knows" it is authoritative > for > > "pbx.com". The SSP knows it is a relay for "pbx.com". External > parties, > > relying on RFC 3263 resolution, find the relay at SSP instead of the > PBX. > > > > Incoming requests arrive at the SSP with a target of "pbx.com", and > the > > SSP routes those requests on to pbx.com unchanged (except for a > recorded > > route). The pbx doesn't bother to do a 3263 lookup, because it is > > configured to use pbx.com as as local domain. This is a common model o= f > > operation for email systems dating to UUCP days. It would have worked > on > > unmodified dynamicsoft proxies from 2003. > > > > Where's the confusion? > > > > Certainly there is a possibility of a misconfiguration. The SSP could > > think that the PBX is authoritative for "pbx.com" while the PBX > doesn't, > > and this would cause a loop. It's an evident and obvious > > misconfiguration. If it hurts, don't do it! > > > > From the PBX's point of view, the SSP is just a relay proxy, what we > > would have called an "outbound proxy" ten years ago (before draft-ietf- > > sip-outbound changed that). No explicit signaling indicator of this > relay > > behavior appears to be needed; it's just basic RFC 3261 on the wire, > > augmented by relay policy at SSP and an "outbound proxy" setting at > PBX. > > > > The real question is how PBX informs SSP of its current route and > status. > > Is it static configuration, REGISTER, or something else? > > > > -- > > Dean > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From D.Hancock@CableLabs.com Wed Jan 20 09:25:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5902F3A67AF for ; Wed, 20 Jan 2010 09:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIG5sNW4Ove8 for ; Wed, 20 Jan 2010 09:25:28 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 074403A6403 for ; Wed, 20 Jan 2010 09:25:27 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id o0KHPNq0017866; Wed, 20 Jan 2010 10:25:23 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 20 Jan 2010 10:25:23 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([::1]) by srvxchg.cablelabs.com ([::1]) with mapi; Wed, 20 Jan 2010 10:25:23 -0700 From: David Hancock To: "Elwell, John" , "martini@ietf.org" Date: Wed, 20 Jan 2010 10:25:21 -0700 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQKOXbMA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD09B46A3@srvxchg.cablelabs.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 17:25:29 -0000 The list includes a requirement that mechanism should scale to many AORs on= a single PBX. Do we also need a requirement for the case where there are m= any PBXs on a single network?=20 Something like ...=20 "The mechanism must be scale to support several thousand IP-PBXs on a singl= e service provider network." Thanks David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: Friday, January 08, 2010 10:46 AM > To: martini@ietf.org > Subject: [martini] Requirements - rev1 >=20 > Revised following the feedback since yesterday. Please continue the > feedback. >=20 > - The mechanism MUST allow the PBX to be responsible for its AORs and to > handle requests to those AORs according to its rules. > - The mechanism MUST allow the PBX to receive requests to its AORs that > originate off-PBX and arrive via the SSP, so that the PBX can handle thos= e > requests according to its rules. > - The mechanism MUST provide a means whereby the PBX knows which of its > AORs an inbound request is targeted at. > - The mechanism MUST provide a means of avoiding problems due to one side > using the mechanism and the other side not. > - The mechanism MUST observe SIP backwards compatibility principles. > - The mechanism MUST work in the presence of intermediate "proxies" > between the PBX and the SSP's domain proxy, where those intermediate > "proxies" need to be on the path of inbound requests to the PBX. > - The mechanism MUST work when the PBX obtains its IP address dynamically= . > - The mechanism MUST work without requiring the PBX to publish > reachability information through the DNS. >=20 > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing > SIP service to ordinary subscribers in order to provide a SIP trunking > service to PBXs. > - The mechanism SHOULD scale to PBXs of several thousand AORs. > - The mechanism SHOULD require relatively modest changes to a substantial > population of existing SSP and PBX implementations, in order to encourage > a fast market adoption of the standardized mechanism. >=20 > John >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Wed Jan 20 13:02:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0BA28C0DF for ; Wed, 20 Jan 2010 13:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 QZbqKGtmOfV2 for ; Wed, 20 Jan 2010 13:02:51 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 0A7FB3A67A7 for ; Wed, 20 Jan 2010 13:02:50 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-612637; Wed, 20 Jan 2010 22:02:44 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B591E23F0290; Wed, 20 Jan 2010 22:02:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 20 Jan 2010 22:02:44 +0100 From: "Elwell, John" To: David Hancock , "martini@ietf.org" Date: Wed, 20 Jan 2010 22:02:44 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQKOXbMAAAkkwhA= Message-ID: References: <76AC5FEF83F1E64491446437EA81A61F7CD09B46A3@srvxchg.cablelabs.com> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD09B46A3@srvxchg.cablelabs.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: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 21:02:52 -0000 Yes, of course. I will try to put out a revised reqs list when I have chanc= e, but in the meantime please keep the suggestions coming in. John=20 > -----Original Message----- > From: David Hancock [mailto:D.Hancock@CableLabs.com]=20 > Sent: 20 January 2010 17:25 > To: Elwell, John; martini@ietf.org > Subject: RE: [martini] Requirements - rev1 >=20 >=20 > The list includes a requirement that mechanism should scale=20 > to many AORs on a single PBX. Do we also need a requirement=20 > for the case where there are many PBXs on a single network?=20 >=20 > Something like ...=20 > "The mechanism must be scale to support several thousand=20 > IP-PBXs on a single service provider network." >=20 > Thanks > David >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: Friday, January 08, 2010 10:46 AM > > To: martini@ietf.org > > Subject: [martini] Requirements - rev1 > >=20 > > Revised following the feedback since yesterday. Please continue the > > feedback. > >=20 > > - The mechanism MUST allow the PBX to be responsible for=20 > its AORs and to > > handle requests to those AORs according to its rules. > > - The mechanism MUST allow the PBX to receive requests to=20 > its AORs that > > originate off-PBX and arrive via the SSP, so that the PBX=20 > can handle those > > requests according to its rules. > > - The mechanism MUST provide a means whereby the PBX knows=20 > which of its > > AORs an inbound request is targeted at. > > - The mechanism MUST provide a means of avoiding problems=20 > due to one side > > using the mechanism and the other side not. > > - The mechanism MUST observe SIP backwards compatibility principles. > > - The mechanism MUST work in the presence of intermediate "proxies" > > between the PBX and the SSP's domain proxy, where those intermediate > > "proxies" need to be on the path of inbound requests to the PBX. > > - The mechanism MUST work when the PBX obtains its IP=20 > address dynamically. > > - The mechanism MUST work without requiring the PBX to publish > > reachability information through the DNS. > >=20 > > Also some desiderata: > > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > for providing > > SIP service to ordinary subscribers in order to provide a=20 > SIP trunking > > service to PBXs. > > - The mechanism SHOULD scale to PBXs of several thousand AORs. > > - The mechanism SHOULD require relatively modest changes to=20 > a substantial > > population of existing SSP and PBX implementations, in=20 > order to encourage > > a fast market adoption of the standardized mechanism. > >=20 > > John > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > = From bernard_aboba@hotmail.com Wed Jan 20 13:16:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1773E28C105 for ; Wed, 20 Jan 2010 13:16:47 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+POFDJXDHrx for ; Wed, 20 Jan 2010 13:16:46 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1264022207-7244-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id CB7083A63EC for ; Wed, 20 Jan 2010 13:16:45 -0800 (PST) Received: from BLU137-DS3 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 13:16:42 -0800 Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , "'Dean Willis'" , "'Adam Roach'" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> In-Reply-To: Date: Wed, 20 Jan 2010 13:16:41 -0800 X-Mailer: Microsoft Outlook 14.0 Cc: 'Hadriel Kaplan' , martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 21:16:47 -0000 This is a multi-part message in MIME format... ------------=_1264022207-7244-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1264022207-7244-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from blu0-omc3-s6.blu0.hotmail.com (blu0-omc3-s6.blu0.hotmail.com [65.55.116.81]) by core3.amsl.com (Postfix) with ESMTP id CB7083A63EC for ; Wed, 20 Jan 2010 13:16:45 -0800 (PST) Received: from BLU137-DS3 ([65.55.116.73]) by blu0-omc3-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 Jan 2010 13:16:42 -0800 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , "'Dean Willis'" , "'Adam Roach'" CC: , "'Hadriel Kaplan'" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> In-Reply-To: Subject: RE: [martini] Requirements - rev1 Date: Wed, 20 Jan 2010 13:16:41 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0090_01CA99D2.CE811B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMmxEut9XUNVoWO0yHWnOZz8xtH6gFZiW66AGKDacwCosuGAAILVkJKApPyH4IDOfu4RgJQs8EiArqG+Ro= Content-Language: en-us X-MS-TNEF-Correlator: 00000000B7DA8EB0AE7AC24184A8151FF4B0FB95070064E51AECD354544EB78CB7421E00090D00000001E1E900001F360934CC25714EA252290083BACC8E00002342699B0000 X-OriginalArrivalTime: 20 Jan 2010 21:16:42.0031 (UTC) FILETIME=[DCA593F0:01CA9A15] ------=_NextPart_000_0090_01CA99D2.CE811B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I assume you're referring to this message: http://www.ietf.org/mail-archive/web/martini/current/msg00210.html In it, Dean makes a number of points, including: 1. That the domain pointed to by a NAPTR/SRV/MX RR may not necessarily be authoritative for the domain (it could just be a relay). 2. That while misconfiguration can occur, this is not inherently caused by pointing the NAPTR/SRV/MX RRs to one entity vs. the other, but rather by mismatches in the configuration of the entities. Dean notes: "This is a common model of operation for email systems dating to UUCP days. It would have worked on unmodified dynamicsoft proxies from 2003...." So one question that comes to mind is whether points 1 and 2 can be accepted as points of reference for SIP and whether there is agreement with Dean's statement that: "The real question is how PBX informs SSP of its current route and status. Is it static configuration, REGISTER, or something else?" If there is disagreement on points 1 & 2, the next question is whether MARTINI is the right place to resolve that disagreement. Since these issues relate to configuration of SRV/MX/NAPTR RRs, they arise both in the static case (where static A/AAAA RRs are configured) as well as in the dynamic case (where the A/AAAA RRs may be dynamically updated). Given that, the question is whether this is a problem that is unique to MARTINI scenarios. -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Tuesday, January 19, 2010 12:13 PM To: Dean Willis; Adam Roach Cc: martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 I've been looking at Dean's note (below), and wanted to say something out loud that I've been thinking to myself... speaking as an individual, of course. We asked that MARTINI be chartered with a very short timeline for milestones, because we want to use the output of MARTINI in various places like SIPconnect 1.1, and we need that output really badly. Speaking as an individual, I was hoping that we would nail down solution mechanisms in the charter, but we didn't do that, and I'm actually OK with the tone, pace and direction that I've been seeing in discussions about solution mechanisms so far ... ... but I'm very concerned about the idea that MARTINI would need to nail down the details that Dean is describing here, in order to produce a solution specification. I'm not saying that Dean thinks this is necessary, but I am hearing other people talking about whether it's necessary. ------=_NextPart_000_0090_01CA99D2.CE811B70 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IioVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgB0DQAALAAAAAsAAgABAAAAAwAmAAAAAAALACkAAAAAAAsA KwAAAAAAAwAuAAAAAAAeAHAAAQAAAB4AAABbbWFydGluaV0gUmVxdWlyZW1lbnRzIC0gcmV2MQAA AAIBcQABAAAAPgAAAAEDJsRLrfV1DVaFjtMh1pzmc/MbR+oBWYluugBig2nMAqLLhgACC1ZCSgKT 8h+CAzn7uEYCULPBIgK6hvkaAAALAAEOAAAAAAIBCg4BAAAALgAAAAAAAABxfXk8bdu8Qa4Ief6x OV37AQDZU5wiYaa7RbnatixwgbPBAQAkAP//AAAAAAMAFA4BAAAAAgEUNAEAAAAQAAAAVJShwCl/ EBulhwgAKyolFwMADzT9P60OHgABMAEAAAAOAAAAQmVybmFyZCBBYm9iYQAAAB4AAzABAAAAGgAA AGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20AAAALABYwAQAAAAMA3j+fTgAAAwDxPwkEAAAeAPo/ AQAAAA4AAABCZXJuYXJkIEFib2JhAAAAAwAJWQEAAAALABRoAAAAAAIB42UBAAAAFQAAABS11YGF HReFTbk7Ij9SzVPOAAAoNgAAAAIB4mUBAAAAFAAAALXVgYUdF4VNuTsiP1LNU84AACg2AwAUgAgg BgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALACCACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAA AAMAdYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwCmgAggBgAAAAAAwAAAAAAAAEYAAAAA BoUAAAAAAAALAKiACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAq4AIIAYAAAAAAMAAAAAA AABGAAAAABiFAAAAAAAAAgGxgAggBgAAAAAAwAAAAAAAAEYAAAAAIIUAAAEAAABkAQAAAgEEAAAA AAAAAAVSZXBseQhJUE0uTm90ZQdNZXNzYWdlAlJFBQAAAAAAAAAAAQAAAAAAAAACAAAAZgAAAAIA AAABAAAADFJlcGx5IHRvIEFsbAhJUE0uTm90ZQdNZXNzYWdlAlJFBQAAAAAAAAAAAQAAAAAAAAAC AAAAZwAAAAMAAAACAAAAB0ZvcndhcmQISVBNLk5vdGUHTWVzc2FnZQJGVwUAAAAAAAAAAAEAAAAA AAAAAgAAAGgAAAAEAAAAAwAAAA9SZXBseSB0byBGb2xkZXIISVBNLlBvc3QEUG9zdAAFAAAAAAAA AAABAAAAAAAAAAIAAABsAAAACAAAAAQBBVIAZQBwAGwAeQACUgBFAAxSAGUAcABsAHkAIAB0AG8A IABBAGwAbAACUgBFAAdGAG8AcgB3AGEAcgBkAAJGAFcAD1IAZQBwAGwAeQAgAHQAbwAgAEYAbwBs AGQAZQByAAALAMCACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4A74AIIAYAAAAAAMAAAAAA AABGAAAAANiFAAABAAAACQAAAElQTS5Ob3RlAAAAAAMAeoEIIAYAAAAAAMAAAAAAAABGAAAAANeF AAABAAAACwAfDgEAAAACAfgPAQAAABAAAAARxZg2hcZARo+4P9nVeFfsAgH6DwEAAAAQAAAAt9qO sK56wkGEqBUf9LD7lQMA/g8FAAAAAgEJEAEAAABPBwAASwcAAJALAABMWkZ1NW5PHAMACgByY3Bn MTI1IjIDQ3RleAVCYmn+ZAQAAzABAwH3CoACpAPk/wcTAoAQcwBQBFYIVQeyEaUnDlEDAQIAY2gK wHNl3HQyBgAGwxGlMwRGFDfeMBKsEbMI7wn3OxifDjB2NRGiDGBjAFALCQFkM4Y2FtALpiBJIGEE EFJ1B4AgeQhgJxigIA0YoGYEkAUQbmcgdBpvHwBoD1EHgXNhZyBlOiAgaAJAcDpoLy93IKAuCJAA MC7ZBbBnLwDAAxAtCsAUUMhpdmUgkGViIWEAIPELgGkvYwhwGKACMCFgAHNnMDAyMTAuvSAwbRiA CrEKhAqASQOgwGl0LCBEZQORAMCiaweRYSBuHcBiEwEgb2YgcG8LgHRzuyVgC4BjCkAPQB7gOiRa 9DEuIBBUFGAFQB9AHeA+ZANxC4Am5AmAHwJieQEmIU5BUFRSL1OgUlYvTVgH8FIlwekq0G5vBUBu BZAfogUQ7mwq0CaAHYB1H0AFsCVAuykwIgEgAhAFwClpKCVAEiAFoHVsKnBqdXPPBUAtUh5hC2B5 KSjhJFSqMijmdx9QbB3gbQQA4QWgbmZpZwhwLgECIPMvgAORb2MjASVgH0MPUf8sUguAKXAjMi0h M4AwACph/yrBJvMe0ylxKx0EIB8RAiDPHeAjQSVAKtB2cyjgKWL3LGA1ESVgYi2QHmApMDUR9yqy MnEAwHQUUAeRKeEpYv8yrCbBKWI4kwiQORAkWiWD9yxRB5AoCyIpEDRUJjAFoD5tBGAlsQRxAyAm wW9wFwSQMyQuYmUhciBzeTcwEEKQBCBkLgEe5FVV3ENQQ2FDACjgSTHxL6N3FGAuMUTwciXwKnAz UXUebgRhBpAIkCpwZHlusmEycGNzJsAFQHADYC54PZEuUANhIAHQMDOqLkjBIiRaUzg0cQpQ/zAQ M0IfQCkxQLEHkR8RMnB+bipwD1EyEBSgOmIm9CB+MR2AS9EUwDOCLVIz0GX/BTAqYR2QTKYmwR5z CfAssPkuU1NJREBNQkw2OZId4L9AYgnCB4ACMDIAJUBoJXP+JwQgMBApMFIkStIgAD9NPx5SB0BK OA9RLbAH4FBCzyvAC4AuYUNBU1NEQCbB/yVABCAjBR5gCGAOsE0zU0L/MABEoTRhBUBTQg3gO+wl YABSRUdJU1RFUv8lYAWxR2AHgB9BHuEwoBSQ9D8iVDtJPONRhA9BUej7M1FMtyZIcDQSHeAskA7R A1WqTDZNQVJUSU7vHXAPUSliBRBnIDAm4Atg70/hHxEYoEdgbC4xStNe2v0o4VMncWTCB5BRkh2w B5HfMJJYwR8RO/8rdC8rEzfS/2CTKtEFEGaxBuBSoTuFWhY7HZAd4ChMMR5BWhVBL75BbVE30wrA O9gJgClOkv0iQGwDIE6hO4VG9Wv7KWI/bTksEi1RRvUHQC0hdXDnQ3FuoSjhIEciAUq0YJT/YU9R I0A2R7ECYEKQSsQPUf1GQGlKQR8CYoYE8AnwLPHWbzkRJFotepJPY3ELgN1VcU0fpHqTJFRGA2Eg AA5TQcBP0QXARGF3a5sLgAQgWyFyHxA6c30EfkBE8EvQBJAUYCOADrByvSEiXTEVBmACMCAAVEpR a0RhJWBKAHB1CsAq0DEeOSVgAdAj4E0QMjoxajNWkE0kVFR+UCV0V/UDEGwEADsRQENwSGAIAGUA 0GgkVENjIAAihUBjIOaEUEhhZAiBAyBLjmELUQuQSYR1YmoFkP1UEVIf8X3xIqOAAIigSkCuaRig UjIEIC0eYXYbc70klycuMSaAdFEYMG99oX8e8CkxUtU+4i9AJoAYMHf+KSVgUJMAcCpVH8Aq0FxI /1ihjAEnsErEi3hcgoxDS4L/QwAwoCEQSMBC4EHAJeCMU78mESUhS9AiAA8wgaBsW/GvJtAvkRSB PctXLWFzRdL/StNihi1RFFJ/kSphUoMmMPsiEIHBcy2xKUEHcYQgOGH/LmIycDJAMBA4USdBJoA1 o79vAY5DHwKa4jlDLZBwOgH3JsFihwOgdnliMABjxAQgf4QgJfBQQjKhLJEFQCjQMf+N9WDSliac VVVSLSKG4C0gfz3LfPGS75P1HXCOUFZCcH82lDHiRYIvskcQAxEpoHf/A6BkgS2QM0IHgBRRAwA6 8N87aJdkOdSbIQ9AZFMAZRH/HyJ0ok1Ci3BIYADQWWBzE/xPS1J0KWKaMiVgCrBP4X9NQg9AGKCI YEqXi3gUkGX/HtIp4Q9BIwAEEDNBJhEG4P86Aab/Q0FHYC5QCsFIwSRa/5JyOfKq4phjMqF9MSyQ ToH/sGMpYg8wJZCWTKX1oGMfIP+mWCljFKAhgWMSjJVekweQ/wUBDyAe4TUSJ1JcAQSBHwLfR7GU AKzysKh+cWNGkTOA/zMyRKGq8SxSjvGlNyWDkVP/YxI0VSylgUGzkx2ASGApcHcs8Y+iTGRlQbAy QQGQbH+MRLBjTDYlQI0CwFY9y30BxfAAAwANNP0/rQ4CAX8AAQAAAI0AAAAwMDAwMDAwMEI3REE4 RUIwQUU3QUMyNDE4NEE4MTUxRkY0QjBGQjk1MDcwMDY0RTUxQUVDRDM1NDU0NEVCNzhDQjc0MjFF MDAwOTBEMDAwMDAwMDFFMUU5MDAwMDFGMzYwOTM0Q0MyNTcxNEVBMjUyMjkwMDgzQkFDQzhFMDAw MDIzNDI2OTlCMDAwMAAAAAADAAYQg68uSwMABxAECAAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAA ZQAAAElBU1NVTUVZT1VSRVJFRkVSUklOR1RPVEhJU01FU1NBR0U6SFRUUDovL1dXV0lFVEZPUkcv TUFJTC1BUkNISVZFL1dFQi9NQVJUSU5JL0NVUlJFTlQvTVNHMDAyMTBIVE1MSU4AAAAAWqA= ------=_NextPart_000_0090_01CA99D2.CE811B70-- ------------=_1264022207-7244-1-- From dean.willis@softarmor.com Wed Jan 20 19:50:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC22C3A67E6 for ; Wed, 20 Jan 2010 19:50:57 -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 ir3jmn8dtijB for ; Wed, 20 Jan 2010 19:50:56 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D349C3A67AC for ; Wed, 20 Jan 2010 19:50:56 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0L3omvD018378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2010 21:50:50 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> Message-Id: <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.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, 20 Jan 2010 21:50:43 -0600 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 03:50:57 -0000 On Jan 19, 2010, at 2:13 PM, Spencer Dawkins wrote: > ... > If I'm reading Dean's note correctly, he's saying that all this is > business-as-usual for RFC 3263 DNS routing, RFC 3261 REGISTER-based > routing, and (he didn't say this, but I'm extrapolating) whatever > mechanism we end up selecting for MARTINI, so the problem isn't > MARTINI-specific, and shouldn't be a MARTINI dependency. I said: > The real question is how PBX informs SSP of its current route and > status. Is it static configuration, REGISTER, or something else? We have a standing practice of using static configuration, and know that this has severe limitations in a DHCP world, so what we're trying to do is standardize a dynamic binding mechanism between PBX and SSP that overcomes those limitations. And I think THIS is the "MARTINI" question. Hadriel's draft proposes overloading REGISTER to inform the SSP. Adam's draft proposes an event package which is PUBLISHed to SSP to inform it. MARTINI picks one (r invents yet another solution) and standardizes it. Maybe if there is a great deal of confusion over what SSP does with the information (which AFAIK is use it to add a Route: header field value, or possibly a vector of values) then we need to document it just to clear up the uncertainty, but to my mind there is no uncertainty here; there's only one thing that is reasonable to do, and the other things people have proposed that SSP might do are pretty clear unhinged. Personally, I think it would be very useful to advertise a routing vector rather than a single hop, and REGISTER semantics really only allow for a single hop. I believe that this is a design flaw in REGISTER, which is responsible for a great deal of the complexity in Outbound, Service-Route, and Path, all of which should have been more properly resolved just by fixing REGISTER so that it records a route- vector (list of routes) rather than a Contact. And I wish that solving this weakness in REGISTER was the goal of MARTINI, because that would be very very cool. -- dean From john.elwell@siemens-enterprise.com Wed Jan 20 23:44:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85603A69AE for ; Wed, 20 Jan 2010 23:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 GY3Iml8+jJgO for ; Wed, 20 Jan 2010 23:44:06 -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 A3B393A689B for ; Wed, 20 Jan 2010 23:44:05 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-615044; Thu, 21 Jan 2010 08:43:59 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id F088B1EB82AB; Thu, 21 Jan 2010 08:43:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 21 Jan 2010 08:43:58 +0100 From: "Elwell, John" To: Dean Willis , Spencer Dawkins Date: Thu, 21 Jan 2010 08:43:57 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqaTPEObycxHnxnSJ6mclAW6OqUngAIFdnw Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> In-Reply-To: <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.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: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 07:44:07 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 21 January 2010 03:51 > To: Spencer Dawkins > Cc: martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 >=20 > On Jan 19, 2010, at 2:13 PM, Spencer Dawkins wrote: >=20 > > ... > > If I'm reading Dean's note correctly, he's saying that all this is =20 > > business-as-usual for RFC 3263 DNS routing, RFC 3261=20 > REGISTER-based =20 > > routing, and (he didn't say this, but I'm extrapolating) whatever =20 > > mechanism we end up selecting for MARTINI, so the problem isn't =20 > > MARTINI-specific, and shouldn't be a MARTINI dependency. >=20 >=20 >=20 > I said: >=20 > > The real question is how PBX informs SSP of its current route and > > status. Is it static configuration, REGISTER, or something else? >=20 >=20 > We have a standing practice of using static configuration, and know =20 > that this has severe limitations in a DHCP world, so what=20 > we're trying =20 > to do is standardize a dynamic binding mechanism between PBX and SSP =20 > that overcomes those limitations. >=20 > And I think THIS is the "MARTINI" question. Hadriel's draft proposes =20 > overloading REGISTER to inform the SSP. Adam's draft proposes=20 > an event =20 > package which is PUBLISHed to SSP to inform it. MARTINI picks one (r =20 > invents yet another solution) and standardizes it. >=20 > Maybe if there is a great deal of confusion over what SSP does with =20 > the information (which AFAIK is use it to add a Route: header field =20 > value, or possibly a vector of values) then we need to document it =20 > just to clear up the uncertainty, but to my mind there is no =20 > uncertainty here; there's only one thing that is reasonable=20 > to do, and =20 > the other things people have proposed that SSP might do are pretty =20 > clear unhinged. >=20 > Personally, I think it would be very useful to advertise a routing =20 > vector rather than a single hop, and REGISTER semantics really only =20 > allow for a single hop. I believe that this is a design flaw in =20 > REGISTER, which is responsible for a great deal of the complexity in =20 > Outbound, Service-Route, and Path, all of which should have=20 > been more =20 > properly resolved just by fixing REGISTER so that it records a route-=20 > vector (list of routes) rather than a Contact. And I wish that =20 > solving this weakness in REGISTER was the goal of MARTINI, because =20 > that would be very very cool. [JRE] But the problems have been solved for REGISTER using Outbound, Servic= e-Route and Path, so it is a simple matter to reuse those. John >=20 > -- > dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From dean.willis@softarmor.com Thu Jan 21 23:25:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3230F3A679C for ; Thu, 21 Jan 2010 23:25: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=[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 nAGcNdGpfjAN for ; Thu, 21 Jan 2010 23:25:08 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6D8283A659C for ; Thu, 21 Jan 2010 23:25:08 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0M7Os4o001115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 01:25:00 -0600 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 22 Jan 2010 01:24:48 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 07:25:11 -0000 On Jan 21, 2010, at 1:43 AM, Elwell, John wrote: >> > [JRE] But the problems have been solved for REGISTER using Outbound, > Service-Route and Path, so it is a simple matter to reuse those. Not really. Adam has effectively pointed out several of the the rather large number of issues related to trying to extend the REGISTER metaphor to cover advertisement of routes for domains and phone number ranges. Although it looks good at first glance, once you really dig into what it means to "register a contact for an AOR" versus "registering a route for a domain", things start to get messy. Consider for example the debate we're currently having about whether the SSP does "contact routing" and replaces the r-URI with a registered contact, or does "domain routing" and just pushes the registered route onto the route stack (really, it MUST do the latter, but REGISTER implies the former, which makes it something of a hack). Seriously, go back and look at Adam's arguments very carefully. He might wear excessively colorful trousers from time to time, but I think most of his arguments are spot-on. Please everybody: go read draft-roach-martini-up-00 and pay very careful attention to Section 9. You claim that the use of REGISTER is justified because the trifecta of Outbound, Service-Route, and Path solves the multi-hop route advertisement problem. Let's consider Outbound, for example. Outbound works for a single contact of an AOR because it allows binding the credentials of that single AOR to the persistent connection established to the contact. Once the "contact" represents a large number of AORs, the security assumptions around Outbound are completely broken. This, by the way, is also the "connection reuse" problem. We really need to extend our AAA model to consider domains and phone-number ranges. Further, Outbound really provides for connection use at only a single relay (the "outbound proxy"), and a general solution needs to allow persistent multi-hop routes (multiple "outbound proxies" in sequence). I might, for example, be behind a NAT router at my house, which is in itself VPNed to a concentrator at my office, which is also NATed back to the Internet, and the "ssp" and "pbx" proxy nodes could be anywhere up or down that hierarchy. There might even be multiple layers of "ssp" proxy involved, and it would be very nice to establish the required routing dynamically rather than having all that static configuration. As the editor of Service-Route and Path, I can tell you that they're pretty conclusively broken in the general model. Sure, they work for the single-point scenarios of IMS that inspired them, but a fully symmetric general route solution would have been a much cleaner solution to the problem. A maxim to consider: an authenticated single-hop route towards a user is NOT the same as an authenticated connection to the user. The same is true of any multi-hop route that is not authenticated all the way to the user. Consequently, an authenticated route to a domain is much different than a route between an authoritative proxy and a contact registered to an AOR homed at that proxy. Outbound, Route, and Service-Route are all based on the idea that we have a unique vector through a singular "sticky point" (the outbound proxy) to a single end user. That, however, is NOT the scenario in domain/range routing, and the assumptions of the security model require careful re-examination. -- Dean From pkyzivat@cisco.com Fri Jan 22 06:11:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD093A67CC for ; Fri, 22 Jan 2010 06:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QMY1mSEOPK1 for ; Fri, 22 Jan 2010 06:11:44 -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 87FDB3A67BD for ; Fri, 22 Jan 2010 06:11:44 -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: ApoEAM1AWUurR7Hu/2dsb2JhbADCL5YugjGCCwQ X-IronPort-AV: E=Sophos;i="4.49,324,1262563200"; d="scan'208";a="234768173" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Jan 2010 14:11:40 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0MEBeGk025869; Fri, 22 Jan 2010 14:11:40 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 08:11:40 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 08:11:40 -0600 Message-ID: <4B59B21B.7040405@cisco.com> Date: Fri, 22 Jan 2010 09:11:39 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2010 14:11:40.0294 (UTC) FILETIME=[D140D260:01CA9B6C] Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 14:11:46 -0000 Dean, I don't think the points you make about security assumptions have been raised before, and they are important. OTOH, I surmise many of those that are requesting this work may have more limited expectations. Specifically, the argument that "the PBX *is* the user" may indeed apply in the case where the PBX is itself a B2BUA and does all the identity management for all the numbers it is responsible for. So perhaps the registration model would be applicable in that limited (but large) scope of applicability. Thanks, Paul Dean Willis wrote: > > On Jan 21, 2010, at 1:43 AM, Elwell, John wrote: >>> >> [JRE] But the problems have been solved for REGISTER using Outbound, >> Service-Route and Path, so it is a simple matter to reuse those. > > Not really. Adam has effectively pointed out several of the the rather > large number of issues related to trying to extend the REGISTER metaphor > to cover advertisement of routes for domains and phone number ranges. > Although it looks good at first glance, once you really dig into what it > means to "register a contact for an AOR" versus "registering a route for > a domain", things start to get messy. Consider for example the debate > we're currently having about whether the SSP does "contact routing" and > replaces the r-URI with a registered contact, or does "domain routing" > and just pushes the registered route onto the route stack (really, it > MUST do the latter, but REGISTER implies the former, which makes it > something of a hack). Seriously, go back and look at Adam's arguments > very carefully. He might wear excessively colorful trousers from time to > time, but I think most of his arguments are spot-on. Please everybody: > go read draft-roach-martini-up-00 and pay very careful attention to > Section 9. > > You claim that the use of REGISTER is justified because the trifecta of > Outbound, Service-Route, and Path solves the multi-hop route > advertisement problem. > > Let's consider Outbound, for example. Outbound works for a single > contact of an AOR because it allows binding the credentials of that > single AOR to the persistent connection established to the contact. Once > the "contact" represents a large number of AORs, the security > assumptions around Outbound are completely broken. This, by the way, is > also the "connection reuse" problem. We really need to extend our AAA > model to consider domains and phone-number ranges. Further, Outbound > really provides for connection use at only a single relay (the "outbound > proxy"), and a general solution needs to allow persistent multi-hop > routes (multiple "outbound proxies" in sequence). I might, for example, > be behind a NAT router at my house, which is in itself VPNed to a > concentrator at my office, which is also NATed back to the Internet, and > the "ssp" and "pbx" proxy nodes could be anywhere up or down that > hierarchy. There might even be multiple layers of "ssp" proxy involved, > and it would be very nice to establish the required routing dynamically > rather than having all that static configuration. > > As the editor of Service-Route and Path, I can tell you that they're > pretty conclusively broken in the general model. Sure, they work for the > single-point scenarios of IMS that inspired them, but a fully symmetric > general route solution would have been a much cleaner solution to the > problem. > > A maxim to consider: an authenticated single-hop route towards a user is > NOT the same as an authenticated connection to the user. The same is > true of any multi-hop route that is not authenticated all the way to the > user. Consequently, an authenticated route to a domain is much > different than a route between an authoritative proxy and a contact > registered to an AOR homed at that proxy. > > Outbound, Route, and Service-Route are all based on the idea that we > have a unique vector through a singular "sticky point" (the outbound > proxy) to a single end user. That, however, is NOT the scenario in > domain/range routing, and the assumptions of the security model require > careful re-examination. > > -- > Dean > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From dean.willis@softarmor.com Fri Jan 22 09:14:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B291328C123 for ; Fri, 22 Jan 2010 09:14: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=[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 SeISZCeKE--l for ; Fri, 22 Jan 2010 09:14:34 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D251328C11E for ; Fri, 22 Jan 2010 09:14:32 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0MHEQJD006921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 22 Jan 2010 11:14:28 -0600 Message-Id: From: Dean Willis To: martini@ietf.org In-Reply-To: <4B59B21B.7040405@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: Fri, 22 Jan 2010 11:14:20 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59B21B.7040405@cisco.com> X-Mailer: Apple Mail (2.936) Subject: [martini] User vs route authentication (was Re: Requirements - rev1) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:14:36 -0000 On Jan 22, 2010, at 8:11 AM, Paul Kyzivat wrote: > Dean, > > I don't think the points you make about security assumptions have > been raised before, and they are important. > Thanks! I try to say at least one relevant thing for every three crazy ones. > OTOH, I surmise many of those that are requesting this work may have > more limited expectations. Specifically, the argument that "the PBX > *is* the user" may indeed apply in the case where the PBX is itself > a B2BUA and does all the identity management for all the numbers it > is responsible for. So perhaps the registration model would be > applicable in that limited (but large) scope of applicability. You have an excellent point. If the SSP were a traditional proxy/registrar that is authoritative for the domain and the PBX were a multi-user telephone adapter with credentials for each user in the domain, such that the PBX could send a unique REGISTER for each user, then we might well be having a different conversation. This conversation would be about ways to reduce the number of REGISTER messages required to effect registration of the PBX as a contact for each user. So we might be talking about "multiple authentication", perhaps extending the digest-authentication model to allow a separate authentication header for each AOR being registered. This would preserve the property that the proxy/registrar has established an authenticated relationship between each AOR and its Contact, a property that is fundamental to REGISTER within RFC 3261 and its current kin. Such an approach would clearly work reasonably well within our current security assumptions, although it should be noted that it does not prevent "identity substitution" attacks in the PBX. For example, if the PBX chose to claim that a call is from Bob when in fact the originating user is Alice, the SSP has no way to determine that this substitution has been made. This is a fundamental property of a shared connection in SIP (or indeed, in multi-user systems in general; how do you know this email came from me and not my sysadmin?) and there's not a lot we can do about it short of requiring users to provide single-use keys for each transaction (the equivalent of me signing this message using PGP). If we scoped the applicability to such an environment, then I'd be willing to accept that REGISTER can be used for a domain, at least to the extent I think it works for an individual user (I think REGISTER is deeply wounded and we've had to put a lot of ugly bandaids on it to keep it from bleeding out). MARTINI could quite reasonably define an extension to REGISTER that works within this scope. However, our discussion recently has centered on models where SSP is NOT authoritative for the domain in-question; rather it is just one of many possible relays that might be used to reach the domain- authoritative "PBX". This model potentially allows SSP to make different security assertions. For example, SSP could assert 1) that SSP is transitively authorized as a route for reaching the domain of pbx.com, and that 2) a request exiting through SSP comes from some user in the domain of PBX. Note that this second assertion is not the same as SSP being able to assert that a specific user in the domain is involved. In this model, only PBX (or perhaps the user itself) can make assertions about specific user identities. The fundamental security question: How does SSP prove to others that it is authorized to route requests to/from the domain of PBX? We don't have a security framework for this in SIP. This leads to the "alt root" problem we recently discussed. What keeps a rogue node from claiming to be authoritative as a route toward a domain? For that matter, what keeps a node from claiming to be authoritative for a domain itself, rather than just as a route toward that domain? Let's start with this second question and work backwards. Our fundamental security model (when we have any security at all) assumes that the node that is authoritative for a domain has in its possession booth the public and private keys needed to cryptographically assert that domain. This understanding comes from the basic references of TLS in RFC 3261, and is echoed in our various documents (draft-ietf-sip- certs, draft-ietf-sip-domain-certs, etc.). So if we make a TLS connection to a node, and that TLS connection uses at the other end a trusted cert for the domain in question, then we assume that the other end is trusted to assert identities within that domain. RFC 3274 provides a transitive mechanism for assertion of identity in the context of a SIP request message that is also based on this model of certification. So what we need is something like RFC 3274 for route certification. This has to allow for route redistribution and aggregation, since there might be more than one relay proxy between the source and destination of a SIP request. Adam's draft-roach-martini-up-00 defines a possible syntax for a "route" (using XML), as well as a means for advertising a route (PUBLISH). One can readily envision adding a signature to this syntax. It's straightforward then to go from a single-hop route to a routing vector, where each hop in the vector is signed by the next hop, providing a fully certificated transit chain to the destination. -- Dean From adam@nostrum.com Fri Jan 22 09:16:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF4D3A6A72 for ; Fri, 22 Jan 2010 09:16:25 -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, 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 9H2QvWM+ovKc for ; Fri, 22 Jan 2010 09:16: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 DD62F28C129 for ; Fri, 22 Jan 2010 09:15:56 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0MHFhJZ012912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 11:15:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B59DD3F.5030509@nostrum.com> Date: Fri, 22 Jan 2010 11:15:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050403060802000800080604" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:16:25 -0000 This is a multi-part message in MIME format. --------------050403060802000800080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit "On 1/22/10 1:24 AM, Dean Willis wrote: > Consider for example the debate we're currently having about whether > the SSP does "contact routing" and replaces the r-URI with a > registered contact, or does "domain routing" and just pushes the > registered route onto the route stack (really, it MUST do the latter, > but REGISTER implies the former, which makes it something of a hack). I'm not sure it must do the latter. I think there are some people here whose use cases will work if you do it that way, but I think a careful examination of everyone's position will show that it simply won't work for others'. On the other hand, the "contact routing" approach, as far as I can tell, will work for all the use cases described so far, as long as we have the ability to define a mapping from AOR to contact URI in some sensible fashion. The martini-up draft gives an existence proof of such a mechanism -- and the mechanism is hardly NOTIFY-specific. It could be used just as sensibly with REGISTER. So, let's take a quick look at the "contact routing" approach versus the "domain routing" approach. I hope you'll excuse that I'm stepping slightly outside IETF norms to convey these concepts clearly: to save the confusion among "example.com," "example.org," and "example.net," I'm going to use dead companies in my example; I'm also going to use inline images for my diagrams. Ignoring how the information gets there in the first place, the "domain routing" approach looks sensible at first blush for this kind of application. Here is an SSP and two of its customers. Through some non-DNS mechanism, the SSP knows to route the domain "pan-am.com" to the Pan Am PBX, and to route the domain "braniff.com" to the Braniff PBX: Great. Aside from the somewhat nonstandard determination of the next-hop server at the SSP, this is pretty normal handling. That said, MARTINI has a special relationship with phone numbers. They're in our charter: " The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included." So, let's explore what that ends up meaning. As long as we expect some external party (not the SSP) to determine what domain each E.164 number belongs to, then everything works the same as my previous example: And, if that's good enough, then great. But I'm willing to bet that at least one person working in this space looks at that diagram and says, "No! That's not what I meant! I want the SSP to handle the number mapping." Now, if we stick with the "the SSP does not rewrite the URI" approach that Keith and John are rather adamant about, the only thing we can really do in terms of "these numbers go here, those numbers go there" looks something like this: I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this: But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" (and a similar one for +15005550200). Okay, great. So the "contact routing" approach works fine for the later cases. But what about the people who want to register entire domains? That's the neat thing about the "contact routing" approach -- if done correctly, it works just fine for those cases, too. Going back to the first example; if we perform normal "contact routing" -- URI rewriting and all -- and have the PBXes register their IP addresses as the mapped contacts, everything works fine: This is great! Now we're using REGISTER to put an AOR to Contact mapping in place (like it always has) instead of using it to install rules to override normal RFC3263 handling. Best of all, we're not saying "ignore DNS and use this alternate mechanism for turning names into addresses" like we have to with the "domain routing" approach. So, Dean: can you explain what breaks if we use "contact routing" for all the use cases described so far? /a --------------050403060802000800080604 Content-Type: multipart/related; boundary="------------050403010308000002090704" --------------050403010308000002090704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit "On 1/22/10 1:24 AM, Dean Willis wrote:
Consider for example the debate we're currently having about whether the SSP does "contact routing" and replaces the r-URI with a registered contact, or does "domain routing" and just pushes the registered route onto the route stack (really, it MUST do the latter, but REGISTER implies the former, which makes it something of a hack).

I'm not sure it must do the latter. I think there are some people here whose use cases will work if you do it that way, but I think a careful examination of everyone's position will show that it simply won't work for others'.

On the other hand, the "contact routing" approach, as far as I can tell, will work for all the use cases described so far, as long as we have the ability to define a mapping from AOR to contact URI in some sensible fashion. The martini-up draft gives an existence proof of such a mechanism -- and the mechanism is hardly NOTIFY-specific. It could be used just as sensibly with REGISTER.

So, let's take a quick look at the "contact routing" approach versus the "domain routing" approach. I hope you'll excuse that I'm stepping slightly outside IETF norms to convey these concepts clearly: to save the confusion among "example.com," "example.org," and "example.net," I'm going to use dead companies in my example; I'm also going to use inline images for my diagrams.

Ignoring how the information gets there in the first place, the "domain routing" approach looks sensible at first blush for this kind of application. Here is an SSP and two of its customers. Through some non-DNS mechanism, the SSP knows to route the domain "pan-am.com" to the Pan Am PBX, and to route the domain "braniff.com" to the Braniff PBX:



Great. Aside from the somewhat nonstandard determination of the next-hop server at the SSP, this is pretty normal handling.

That said, MARTINI has a special relationship with phone numbers. They're in our charter: " The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may be included." So, let's explore what that ends up meaning.

As long as we expect some external party (not the SSP) to determine what domain each E.164 number belongs to, then everything works the same as my previous example:



And, if that's good enough, then great. But I'm willing to bet that at least one person working in this space looks at that diagram and says, "No! That's not what I meant! I want the SSP to handle the number mapping."

Now, if we stick with the "the SSP does not rewrite the URI" approach that Keith and John are rather adamant about, the only thing we can really do in terms of "these numbers go here, those numbers go there" looks something like this:




I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this:



But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" (and a similar one for +15005550200).

Okay, great. So the "contact routing" approach works fine for the later cases. But what about the people who want to register entire domains? That's the neat thing about the "contact routing" approach -- if done correctly, it works just fine for those cases, too. Going back to the first example; if we perform normal "contact routing" -- URI rewriting and all -- and have the PBXes register their IP addresses as the mapped contacts, everything works fine:



This is great! Now we're using REGISTER to put an AOR to Contact mapping in place (like it always has) instead of using it to install rules to override normal RFC3263 handling. Best of all, we're not saying "ignore DNS and use this alternate mechanism for turning names into addresses" like we have to with the "domain routing" approach.

So, Dean: can you explain what breaks if we use "contact routing" for all the use cases described so far?

/a
--------------050403010308000002090704 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example.png" iVBORw0KGgoAAAANSUhEUgAAAk0AAAEwCAYAAACqrkXaAAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB3wcNfZ+s+uaTnol CQECIfQOocPR+wFHOfqfox9wHL04dK7BUY9yEEIn9H7U0HsaSQiQSojj9OLYsdf26P99Myvv eLGTteNdb3nPv8/SaCSN9Ekz8/ZJI4moKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgD yoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAM KAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAy oAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDLQpgw4bXr1NLp4UV/XRXGUjzRq k1YoiqkqDYVaIZ+My0L7c8Y1WSIFztn+nAg5GkcZSAUDeam4SIZcw1k9T3WmDGmrhIpZ3M/k coNqf06ol2ROpBzvz5nTUFrSrGYgJ3+FZ3WLauWUAWVAGVAGlAFlICkMqNKUFFo1U2VAGVAG lAFlQBnINgZUacq2FtX6KAPKgDKgDCgDykBSGFClKSm0aqbKgDKgDCgDyoAykG0MqNKUbS2q 9VEGlAFlQBlQBpSBpDCgSlNSaNVMlQFlQBlQBpQBZSDbGFClKdtaVOujDCgDyoAyoAwoA0lh QJWmpNCqmSoDyoAyoAwoA8pAtjGgSlO2tajWRxlQBpQBZUAZUAaSwoAqTUmhVTNVBpQBZUAZ UAaUgWxjQJWmbGtRrY8yoAwoA8qAMqAMJIUBVZqSQqtmqgwoA8qAMqAMKAPZxoAqTdnWolof ZUAZUAaUAWVAGUgKA6o0JYVWzVQZUAaUAWVAGVAGso0BVZqyoEXnLzCyerXJqJpEIplV3owi N8MLq/05wxtQi68MZDEDqjS1QeOefoGR4n4xbLidkUuuMVJb6ysSlVCA2g8wcsq5DRWLN94x stP+sbD/PGpklwOMHHCMyGa7ihx5spEFi2Lng1XbaPvY9XjtXpsYOfA4I7+WNh4/mLa1/UuW GhmwhYgxqb92a9dF8xPR/qz9We8DZSBXGFClqQ1a+ruJIs88LLJ6niMrZvn+t94X+dvdfmEm ThZp307k5bdEli6LKRbjJolsA2WD8t5HRl58XeS1p0QmfuzIlM9E5s0XGfW0fz74f+FiKkci pVP8a/K6kz5BOlzn4ceDMVPj/3aCyFabiziOk5oL6lWSyoD2Z+3PSe1gmrkykEYMqNKU4sYo X2Xkpxkx5aegwJHttnLkJFiL3v/ILwyVowP3Edl8U5GnX4wVkC+nbbf0j0f+TWR/xOnW1Vc8 iosdue1akf32jMW3vnFIN2SwyHpdYkpKrx6ODOgn0r+vH2sxrD9nXGiEVq/9jzEyfWZMWXvm JSNb7u6fu+bmWPgLrxnZdm8jPYcaORlWsYpK/9wtdxgoY0ZOOtvI/bCGVVcbufQ6I8NHGDnu DCPvjo3Vw5ZR3cxkQPuz9ufM7LlaamWgZQyo0tQy3lqcavz3It27ChSWmALDzIqLRAoK/Wyp 5GwNi9LpJ4o8CkuSlfG0NEWVpn59RP4OyxSVEVqdqqqM7L27A0tUw3yZlsoWLVScR0SUlhlY tYwsXyHyh6P83A/HtQatL/K/Mb6ydvZf/PDnXjZy4z9QjntgxbpX5L5HRL6dYOTTr4zccofI 6Ptw/IHIDz+JPDTaT/PWeyL/flBky+EYMjxY5LzLRGbMFnngXyK9eorc+9+Y0uin0P+ZyoD2 Z+3Pmdp3tdzKgDKwDgwU9XUxxSb5csf9rjn0hN9e689Xuebiq/3wLXd3zUefuWZluWu6beia r75zzdx5ruk0yDWRiB9nxUrX3P2Qa3be3zXF/VzTf7hrnnz+t/myRked4hrWLwimmfC9H//1 /7nm2NNjacdNcs36W7imttY1AzZHWT6PnbvvEdfMnO2ag//gmvc+ioVfeaNrzv6La2pqXNN5 sGveft8/N+dXP49VFf7xjz/75WAeyRbWdx26REYn1f4c61/anzO6K2vhlYG0YkAtTSlujuC8 JHvpujojb78v8sfjRFZVGPl5pm+l6djBkWMO961NTMfhuvx835LUqaMj55/pyOdvOzLtK5ER O9HqZHNs6NJy9TrmOi3+2ccPX8Di00Pkyef9eLf9W+Sjz0U22MZ4OOwE3yL02dewfhWI7Ia8 rZxzmiPLYKGa9YvI3rvZUJGV5SK0fk3DNXp0w9Dh3n4578XcrRMx9Ni+nX9cCGtal84igwf+ 1iIWy019mcKA9mftz5nSV7WcykBrMKBKU2uw2Iw8OFTGobegjH5WpFNHhG/uCIc7OEzWuZOv VHCIbswrUGow0dsOzfELunfHxowo62Oo74/H+kN8wXzp51Bc2UKRHbbxFRcqL4PWd2TXHUXy 8vzYvOabKMO0L31MxrU+xDV/niHSp1dswja/zPv4cyMTEL9X91h4TY2v9J16vIg3hBio3wRM NqeCZuWlN3RoznKRDa72Z+3P2dCPtQ7KQKIMqNKUKFOtEG/5CiMzZ8eUJlqV7nvEyM2Y6/PI Xf4FaBWyX8gxZPutHVhl8JXbE5g8HVVGqE69/7Efn/85GffB0bDo/D4WZn3Mb8MNRGi1CkrZ ApGNEI4hMihosBzNoVXJkbJFIjv+TrzJ6gxfiONly43QGnbOpSIrykXa4cu+UqRnOOWRJ0X2 gtWpf19f6eOXcVY6tBeZivlOLkbK5s3nxHCdBG65yXRX+7P250zvw1p+ZaC5DERtDc1NpvFb wgCtMJShO/C/8aw4e+wi8iqUjmFDfaWGSs7WAaWDMWltuuSamKXpxqsEX6thSYI38eUaLD5V 1SL77iFy3V8Zu6Fw+CQ+P8aYPVfwtZtvLbr6En79JvKPe4wsWSpyy7W+1WujDYzccT+GBUf4 w3UH7ydy6P4OhuKM/Os+f20oxuGQ26N3+9elFeqyC2NluPD/RA7/o8jnX4tQgeqPITxrMYvF Ul8mMqD9WftzJvZbLbMysC4MNDQ/rEtOGZ6WE2e5flGmCFcA59IFXdf77Zd4LanDoiUYxoP1 aOiGvsUpmMcv84yn7IRCMX5oeeL1OT+pT69YeDCd9dMisWixb/FK5dpMXMSzqjRQaFugHHC1 P2t/zoFurlVUBlLOwJrfdikvTttdMNNeMm3HVOZcWZUmvb0zp7euvaS53J/Xzo7GUAZSw0Ao NZfRqygDyoAyoAwoA8qAMpDZDKjSlNntp6VXBpQBZUAZUAaUgRQxoEpTiojWyygDucIAl6Dg V5mpEq6GT1hZsTLmt2HqKgPKgDLQGgyo0tQaLGoeyoAyUM/ABlgTbD4+KkiWcB/Ez7/xFaOr buK+iP42PW+/b2QLnOMSGCrKgDKgDCSDAV1yIBmsap7KQI4ywC8tuQRF397Jm4T+1IP+V55z fjXefodzsExHO2xYffZfjIy8nPsdJu/aOdqsWm1lQBmIMqCWphR3BS5oeeBxRh572sgO+xkZ PsLI2E9jwwljXjHyu6ONbLS9kTP/bIRDHZSRf+MvaCPHnu5vdXIW1lZqagjkp+lG/niOH+/Q E4yMm+Tn8fEXRs79q5GS240M28XIqecZrEBuZJ8jjGyM641+JlaOIC3Mj2XuM8zICWcZmf2L H2/GLCOHnYi1ooYaLIhpZOLkdbtO8Jrqz0wGuM7Yxli24vQLsEzFcCMHHGuEK8lTbrnDyMOP GznpbC4K6S+YesUNvnWI98KDj/nx2K/3PtzIq28b2eUAI0N3NPL0i/45bhTNhVwn/yByxElc nJX3BhSlk9nPudaYSCWW4wgKl+e45Boj629hZLeD/Xx5nkN6l4/07xNuIcQyUXj9vXD9p17w 4zPN1+OM8J4bsq1/33CxVhVlQBlQBnKWgVRtcPrJl/4Gu1fc4JpZc1xz6XWu2WI3f3PRGbNc M+Ig13zxjWtm/+KaTXd2zdhP/XPb7eOaHfZzzWdfu+bx5/xNb7mJb7y4eJrvd7RrnhjjmgWL XHPuX11zwRV+vFvvdE2PjV3z0GjXvPOhX45dD/SvwQ136Y+XsoWuGbila0Y/45rpM5H3Ua5h XG4cPHyEa5572TWLl7jmshLX7HZwy68Tf93WOGab5mqHTlV/jm+na29xTc+hrvnvE6759CvX bLara6652e8X7NvsM3+72zXzF7jmrgf9TZ5nz3XNq2/7m06z//403e+bZ13iGm7wfPI5rtnj 0FjfYn8uX+WaMy50zV+vdw376LMvuYYbXbOPxstxZ7jmzD+73v124z9cs/EOfhxukM28mJ73 Q8eBuO9QFl6f/PHe4WbZO/7ONV2HuOaxp/2NtHmO8VItudyfc/U+1norA2nLQKpeMnxR8OVh hS8FPqwp0+C3D/3SMl+ZencsFt1c7Zr2A1wz9Uc/Xm2t/1BfstQ1c351zZRpPioqXbOy3DUf f+HHq6pyzZ+v8l9MzP/Y013DlwaFSg/r/NFn/jGVHypb8XL+5a658MpY+Eef+y+4R59yzTmX xsK/Ge+/LJm+JdeJv25rHOfySyZV/Tm+nQ46zjUlt8f6BX8UUOmpqXFN58Guefv92LkPP3FN JfosFaX3PnJNr038c1SAtt3bNXV1/jH75v7H+H4qQI886fvZX9981/c/MMpXouLLwx8dg7Zy De8ZChV8/nigorTx9q6prvbDeY7KFO83Xn/rPf1yMfyY02L3AO+bdv1dswj5pFpyuT+n7YtD C5ZzDOicphQ3ObeeOPrQ2EW5l1ufnv7xYmxhctcDIl9+i6GNvv7+b9zHbfI0rvotsunG/lyN 6bNEenTjauCON2w2aYqf/ocvxJtP8ua74g3thTD4WlUlcsWf/fPc4uSKi3z/1B+5V5zI7rv4 eXK4Y/gm/jn7Hy8FefUtkWcetiGIv7PjDV9stqvIkyirlXLUo29v/6i517F5qJv5DHCD5lH3 xurhoHux70772e+z++/t9zfoScJ+fPXNIr+W+ivbb7GZn455HLC3iF2BnivPb7KRf473z+Xo z+ybExHP7nPobRe0Rey61vfSmyK/P0wkHPav262r490P19xs5JjDY6vfM79VFX4f/uATEW4Z ZFevn4J75S/n+TnyvuG91x35qCgDykDuMaBzmlLc5ny4c6NcK0+/IHIQHtClZZyvBGUH+7TN +E7k7zeI9OvjP5yphGy3lU0h3twN+7L49A1soouXDzFofQfKEl4QaNWv3hGZ+BFfCv6LZeky zC3BViZWMRqPPIN70jW2R92KldiwF2n6Qbmywnkmi5b4G/z2jip7PPf8ayJnnSLSkuvYvNXN bAZmzeGn/1QqYorRq2+LnIG5R1R2ghtRj3pa5LFnREZjD8M5Ex3ZB1/AbTXcrz/75raB/s7+ vzXOsW/NX4g9D4f6/a+4KLaFDxUte08EWaTCxfvIyncTuWk25j8hz969bKjIh1CUhm3s7wEZ vD6XL/jlV5EthvlxWZbGrhPLSX3KgDKQzQzg9aqSKgY4CZwPcW6WS5n2s5HnXhY57QSRF18X 2XUHkf32dLyNdKn8bBl4iQQVHD647QsoP9+BYuRj/gJMKv9M5Jq/cE84Ry69XmTuPGy4iwc+ 01BhYnwKXwzBh7/3YsIvdU48f/NdgzLgKygoXPwS6kdYCSicKP4Sytm+HfMR4a9uCl9C/HV+ 6h8Sv46fUv9nEwPfYRJ4dQRKEL5qoyXp7odEtt9aZPBA5zf97YnnRM47U2TIYAcKi5H7Hon1 x2D/Jj/sq1ujbzJ8GBQm9vdg/41EjGfJ2jJqqfrqO1ixZhqP2s4d0X+n+5apX0sNJqiLrNcF m0ejD9P6RQsT+/w/obxZa5K9F5gBrVncj7EYX+dRqGwF70UvUP8pA8pAzjCgSlMKm5q/hgfA asN1ZHbe38jhJ2I47jb8it3MkR22EfniG5F9j4TF6QyRQ/cX+W4ClR7jvSysksTi8ld7UOGx VeDGuXyp7HaIyB6HGm+4rEN7kZffRBpcO5gm+Muf1yjH0ASHQCZNFe/63OaWL4pLzsFXSrB+ 8eumZ6Hg/QMWsPbtHLkAL7xDoezxy7vDYEm482Y/fqLXsWVWN3sYoLVy/70xhHswlJtdYH18 VeTma/z6eYrI5rG67g3L0uUl+JFwFL5Se5HDxOinsJrOmWswLCcycICvpHAjaQ5bs197fSv6 QyKYH4fP1u8PRai9n+aU80S+hQJHufAsvxyb74ZhutNgwR1JpcmR8/9PhFbebVHerfYEkO8B +zix6/f387IKm5cZ/gUVKhumrjKgDOQOA/6TIXfq22RNOcly9bzk0nH3Q/jEHy+Wh//NlwOH 02LzJlgwfiq9BC+IAf38cixcjM/5uze/TLT8DBzgz+Pg8EJRIS1Gzc/HkrVkqfEsS506Nsxj 3nx/HsiGg2NzRmyadHBzeYPTVPTnptqYVsqly2L9uKl4tIxSqe/YwZHaWiMry/15ek3Fb2l4 dTXuK5Qnfu0oWn5nzaElLKZwtfQaqUiXy/05FfzqNZSBRBho+BZMJEWWxknFS4Zr12y/jcg5 pyntqehGufySSUV/TkUb6jViDORyf46xoD5loG0ZyGvby+fW1UfsJLLXiNyqs9ZWGVAGlAFl QBnIFgZUaUphS55+olqYUki3XkoZUAaUAWVAGWhVBjDlUkUZUAaUAWVAGVAGlAFlYG0MqNK0 Nob0vDKgDCgDyoAyoAwoA2BAlSbtBsqAMqAMKAPKgDKgDCTAgCpNCZCkUZQBZUAZUAaUAWVA GVClSfuAMqAMKAPKgDKgDCgDCTCgX88lQJJGSR4DXGBw3nzsvQeswOKG3DS1AlhVCawSs2Kl E1m5SmpZguJCCRUVSbi4yORhe5cQt3jhVi89e2AFaawIzVWh+2A/MbvRavJKrTkrA40zoP25 cV6yNLSxz6EbC8vS6qdltfz9kxoWrbGwhjGacaRKUzPI0qjNZ4DbYPw8U2Q69tybPlvqsALz amyAWltaJiFs/FtYVydOcbEsKcyXedgGbIXrysraOrMCe5gtw+avyxzHrAJWinHCxpFCcaWQ bl4oVJhX4LbPD0tRUWFoMPY626AqIn0i1dKuZ3ezekB/pw6lxS5jKspA6zGg/bn1uMzAnKgQ WaUo3m+rY8/bY3VTy0BQQbJ+uo35W1QyVZpaRJsmCjJQV4cNUmeJTP6Bm6M67uQfTOUPPzm1 s+eaYig5tcXt5BcjztTlK9zxUmdKTcjMM647L1JVOU+Wr7d8VTCzBP2RJuPNLZ7n9hxYuiA0 0BWzuMloekIZaIIB7c9NEJO7wUEFiVNaeGxd6yc7wXg8Vkk9A0EFycXl7bH102U72fBml5CJ VcCAbjuRWDfgfniTpvgKEjZorRg/UWpnzcUevkWyJL9AJpWXO99VReqmGdf8VLt69U9S3mlJ YjlrrNZkQPtzYmxqf06MpxyOZRUhulSULMJRP117zsZFkBdGVyU1DFAJolhlyCpJHHGg37r0 23M2LoISF7U0Jc5VzsWcDfvQhMki4yY5tV98YyomTZX8mojX+ZZFMHxWV+feW2fciTWhxZMr fu6LWUgqykD6MtBUfy4ukp+xqe/XFavNd3WuO0n7c/q2YRuUzCpCVJaoIFksh5/nVNKfASpH nKpBxYmgUHGiWGXLP0rgvypNCZCU7VEwH0h+miGegvTdBCfyxbdSOWWaKQ6FpAKTrb8vX+l+ HKkz30WqIuNkabu5Is+FC/v+/n+OcYbUlBU8lO38aP0yi4Hm9udlmVU9LW3qGLBKkVWY+L4k 8gHHYBKmSvozgA+D2I74bEhqANumLDgVKB43qyFVaSJ1OSSRiJGpP/oK0rcTpOrLb6UaClO7 okJZkpcnE5atcD82xv2uWlaPk9JOTcwJOrauunzlcUUdOnxX0Lv220hZ3vM5RKFWNY0YaJ3+ nEYV0qKkEwN8oQaH4/i+xPe63gs4ncqpZVk7A0WIYhUmKkkWdqhu7TlEY6jSFKCqfJWRjh0s r4ETGepdstSffzQRc5C+meCs+m6CcX8tlXYd2ss81PLbZSvMp3XijqutWT6+fE4PfPDfDMFc pbqiyBHh/Lz3CnpX/xApK8RVVNKJAe3P6dQaWpYMZcAqThyWo4WJFgu+gFUyiwHbZlSW7Lwm O0TXrJqo0hSlq1cP80i/4c6JW25mqo482Ol44L4mtOnGmaFAcW2YH34SmQZM/cmpGTfJVGKy dl5FpYQ7dpAfq6ucLypW1X1TF3Yn1JTOmVIhG1U3q5c0EblmUcEE2Du7N3Fag9uQAe3PbUi+ XjpbGIhXmKg00dJUnC0VzKF6sM2oJHFILqg0NVtxygytIFUt27e0XWFdz707dg4fYVw5rKjI tDt0fycEBap46IYiQwZhQDuvbSirqTGC9Y1kNmYUzQHweX9kwmSn8sfpJh+LQhZ0bO/MccRM XrbSfGtqzfeOUzOpqqx4dqqo0+ukIQPan9OwUbRIGcSAtS5RUaKlol0UHeB+pXOawEIGSHSx 4x1RVK5uww+WiCqAK9dwnpOdHA7v2qVtNIC1lystYhT0qd407OQd3GU95+DaGtmkslK69+sr lZtv6shWm0uHYUNNaOMhgiE9TM3vLNKpIwZNvTlniRefk1aXYCbqkqUiiwl8oE9/2UJxYT2q xMKQtb+WOnnLl5vi9u1kKT7r/wXryPy4fLmMx7DsD46pmVq1oGg2rtysyWyJlzCRmMbJ7133 x7CYX6rK8scmkkLjpJ6BdOvP7YplaXWNOAUF8uWqcvNR+vTn1LeNXjHtGOC70SpNHJKjpYJK E57yHjD3sw0fuSiESmIMRN/JuyM2p6AQVJpWAxxxsUpTwo2pShNYS1x+LszvMXBTJz80rDDP 2Rzzn3bACtaDa+ukI1aw7lBTI4V4EVRjzlBN507iQolyI3gp1GITkLo6R2pqjUMXSo8DXUlW rpSCytVSgC/UKgvyZQUmYi9FgyzEithlFRWhmbU1dbPwIgFqZ1eVvTZX5NhmacSJ16sVYvYu 71EUaj/OFff8SGneK62Qo2aRdAbatj8X9Tn6JlSxX9X88MlJr6peQBloHgN8N3L6CofkrJWp PfxUmvj5+ruqNIGFDJCo0rQfisplIqg0VQDW2kSlidt0qdIEEtpASkLS6eIuhUWF67nh0HrY 96NDLXQk/NU6IVOL7zBqnbqoW2tqq/Mjy6T0X7ArlTR7XLUNKrfWS+b3iWwXlry3XKdmt0hp 4bS1JtAIac5A8vpzYY+qjZz8gi+qaiqHy6IOZWlOhBYv9xiwSpOdw0QrE4flMKbgKU1vqtKU GZ0iqjQdhNJSaVoB2GE6Wps4RKdKE0hQaSMGinrXnmpCoauqI0u2lcXN/CKvjcqsl009A4V9 3Lfw4+7d6vnhf6X+6npFZWCtDMQrTVSYaGWi0rQe8KoqTWAhAySqNB2Goi4DqDTR2kTFqUVK E9egUFEGWo2BqrK8URKJHFIQ7jSo1TLVjLKKgaJeqwdjgHp09fzQHVlVMa1MNjJA5ckiuGZT NtY1m+vE+Wm2/Wx70m22cMxWRRloVQaqFxdh8QMVZaBxBqoWFGOenhAqykAmMBB8ydoXbyaU W8sYY8C2W7AtY2eb4WNGKspAEhj4Nj+/d2R76bycpmwVZUAZUAYyiYHgyzXer+/NTGpJv6xs s/h2DB4nXCNt/ISp0ojNY2C7GnyPEC5q1+knTPrdsHlpNXZWMtC9om9RH/dT6bmqV1bWTyul DCgDWc+AKk1Z38RtV8GaBQVfGjHXSF7BK9KrjJ/rquQwA4X5xfe5Yt6QhR0W5DANWnVlQBnI YAZUacrgxsuEouPrqAeMY74sCvd8NBPKq2VMDgOFfWr2h3F8eGT+tH8m5wqaqzKgDCgDyWdA labkc5zzV4iUvnCWcc2HeX1qdst5MnKSgCkF4oTvEVN3vshmXBdFRRlQBpSBjGRAv57LyGbL tEIfW1ddJvdnWqm1vK3DQGHPIQNcU3t8zfyCb1snR81FGVAGlIG2YUCVprbhXa+qDOQMA9UL i2bkTGW1osqAMpDVDOjwXFY3b/pVrrB33bn4guobLNPD/ZxUlAFlQBlQBpSBjGFAlaaMaars KGh1Wfg+bJ8xrajP+g9nR420Fk0xgDlsu2O7lO9FfuYu8SrKgDKgDGQ8A6o0ZXwTZl4Fqub/ 8n/GcYYV9qm7OPNKryVOjIEP88IS/g+2S7lGZKPqxNJoLGVAGVAG0psBVZrSu32ytHSDq6pr Kw/EAq375feNbJOllczpahX22f1CEDAnUpr3Sk4ToZVXBpSBrGJAJ4JnVXNmUGWwwCHMDwdl UIm1qIky0GNVb+wsfpWpieycaBKNpwwoA8pAJjCglqZMaCUtozKQSQy4oXBVbeVm1YuKfs6k YmtZlYFMYuCkk06SgoIC6dChg7Rv31769esnF110kaxYsaJVq3HXXXcJfgTJJ5980qr5Zmpm qjRlastlUbkL+tZdrvObsqhBl7Sbp1ulZFF7alXSloFLL71UVq1aJRUVFTJlyhR588035dFH W3fzhSeeeEJ22GEHefrpp9OWh1QWTJWmVLKt12qUgYgsuBs/ZU7DcgTnNRpBAzOHgfWWdhbB CuAqyoAykFIGunTpIscff7x8+OGH3nVLS0u9Y1qgfve738n777/vhU+aNElOO+00uf3222WD DTaQbbfdViZOnNhoWX/88UeZN2+e3HHHHTJmzBipra2tj3fggQfK6NGjZccdd/SUqrFjx8q5 554r/fv3l6OOOkoqKyvr42aTR5WmbGrNTK1Lad9Kp676cJiAS/L61uyaqdXI9XJT6S0s7vKS bpWS6z1B698WDFDxefbZZ4XKDOWee+6RPn36yLhx4+Tkk0+W888/X4wxnlWK1iMqVW+//bYM HDhQrrkGH7k2Ik8++aQce+yxsvPOO0txcbG899579bG+//57efDBB+XOO++UrbfeWvbdd18v zuuvvy5UtlgWFWVAGUgiA4V9a36HhZLPHWEAACAASURBVC/nS/eKvkm8jGadDAb6ruyOtltU 0Lt6WDKy1zyVgRQzQIMCLaYdgV7AEGBrYC/g9wD0j7aVE0880bAcFqFQyOy3335m+fLlXsE+ /fRTU15eblzXNePHj/firVy50nz++eemW7duBlYjL95nn31mNtpoo0YrM3jwYPPVV1955/78 5z8bKF/18WDBMlC6vGPMdzKYX+VdjwGYW2WuuOKK+rht6YnywzZj27EN2ZZsU7Yt27hZxiP9 eg6MqaQHA9Wl+e+IfLu+SLdwepRIS5EoA4Wm/a1GzOORssKpiabReMqAMrBuDHDit7UScTJ4 UVFsowUOpR1xxBEChUmGDx/e4EK9evWScNh/zHIi+erVqxuc5wGUKZk1a5acffbZ3kTwJUuW yLJly6Sqqqr+OhyKo3BC+vrrr+9NSudxXl6e1NTU0Jt1okpT1jVppldoO95p2Xm3ZXrTNFH+ /N6R7R1xDqmqWbJxE1E0WBlQBpLAAIfMYDX6Tc51dXVywgknyK233irvvPOORCIRb+jMRoRV ynqbdDmEd+qpp8qZZ55ZHwfWLW+yOecsURLJpz5xlnhUacqShsyuanybX9R7qxNdU/ddZEEh tuFQSWcGasoWTK6R6QNg/Y7NEk3nAmvZlIEsZ4AWIVqGDjnkEE+xefzxx5tVYypZzz33nDfn afvtt69Pe+SRR3pf0Vmlqf5EDnnWrm7mEBla1XRhYLsaU1f7WSiU/0F+r8iO6VIqLUdTDAyA bV8VpqbY0XBlINUMdO/e3bMScYI2MWHCBKHywyUKEpG33npLOnfu7KUJxqfS9MYbbwjmSgWD c8rv5FRttbIZxUBhr9pDnHDoP1gocVtd9ycdm+65cEHPwzeLLFz4swgVJxVlIGsYoEGBIzHc bLod0AHoBHQBOB42BpOb4aS3zJ8/31v4slOnTsIhO0wSb3Q4L71rsW6l48KckGOAJcByYCWw CuCaCNwXkxZyF0hI1NKUEE0aqS0YqF6Q9zo+/HioKNzueUwQz2+LMug1m2agsO/Rdzl5eWep wtQ0R3pGGWhLBrjkABUmCid+Nzb/qS3Ll4nX1jlNmdhqOVTmSFl4JCYav1XQa/OhkQUyOYeq ntZVze8R2coxztFVlSs3TeuCauGUAWVAGWhFBlRpakUyNavkMFBTVvB1cnLWXFvKQDg/715Y tK+RFV2WtTQPTacMKAPKQKYxoMNzmdZiOVvenwsLelVjsZG5xTlLQZpUvKB37bGYzVFZVZr3 cJoUSYuhDCgDykBKGFClKSU060XWnYGNqiUU3qiob78fBatPr3t+mkNLGYiU5T1XXRrar6Xp NZ0yoAykhoGTTjrJW3iSC1hy8UvuQ8cFMVesWOEVYKeddvIWpORcJ8596tu3r/eFHSeNc8HL oUOHClYCb1DY/fff39vTrkGgHigDykB6MlDUp+4mbNcxVuQ5XTU8PZtIS6UMZAMDNCik9TYq iWxNwq1WrrzyyvqoWL/J2zIFG/B6Ydhs12ANp/rzWJrA2w7Fbo/y5Zdfmvz8fINNgL04Dzzw gMHkcoM1oOrTpLsH7cjPHH8PtMo2KmppApMqmcNA1fwbr8MdUFXY5+i/ZU6ps6Sk3Rd1LOxd e7DIFL5MVJQBZSDDGOjSpYtnJYIS1GjJN910U+EaT9HP9AVKlfz1r3+V0047TSZPnuxZoR5+ +GHp2rVro+lzIVCVplxo5ayqY4lbPX/ekVgiZXl+38g2WVW1NK9MYUG3V0ScQSKbRdK8qFo8 ZUAZaISBiRMnyrPPPisHHnhg/VlstiujRo0SWJGE26RwP7m99qJRxpfrr7/eW+iSCtRxxx0n Bx10kD2Vk64qTTnZ7Jle6QGrsRTBjTWlBeMyvSaZUn5O/kZZu1aXvfCfTCmzllMZUAbE23+O liNim2228TbWPf744+upmTRpkvzvf/+TDz74wNuglwtgzpgxo/48N+Pdd999pbKyUg4+GIZm FWVAGVAGlIE1MNCrrH1RX3duXt+aXdcQS08pA9nEQNbMacLEb7N48WIPmNzdYApS/JwmnmT8 8847rz4elCqDjYHN//3f/5lBgwaZioqK+nOZ4EGn1DlN2XRnal3WjYGC3nXXF/ZxX8B9oVsC rRuVTaYuDPc4Dfw+Ulua/1mTkfSEMqAMpCUDUHi8lcD5hVxRUdFayzhs2DDhMB6FX9GdccYZ cu6558r999/vDdNdd911a80jmyPo8Fw2t24O1C1S9sJN4kgXfFF3Sw5Ut02qWF0avqeqNHx9 m1w8/S86CUU8IVrMsXDnANyrzAr3LuMvXS6TcTPwERAvTyHgiWigze8yHHPuGFEXhT1mWxwG MN946B6AIEUlcQaqq6u9oTdYkOSll14SfFlXP2/pzjvvlIULF8rIkSO9bVjuu+8+ueuuu2Tc OJ0ZkTjDGlMZSDcGOq7sBqVpNubd8LNSFWUglQxYJYfXHAtwhXQqR1aCShMWZ/UUoJ72JFx+ ichFc+zs2mB+Ntpd8MQvJEqlabKNoG6rM5A1w3PBJQfih9M4PAfm6jFgwABz4YUXmqqqKjN9 +nTTrl0789prrzVIdvrppxvMjTK1tbUNwtP1IFq/VltyQLdRafV7TTNMOQPlnZaYwqr9Q/kF Dxf1qhpXtaBoZsrLkIUXLOxZNcQN5Y2oKQuPxldzfLCqrJ0BLoXxV2AU8DMQFCo5U4EjgAej J/aBWwO8Gz1WRxloNQaeeMIaMBvPEuswNX4CoUOGDBFan+Llv//9b3xQTh2r0pRTzZ29la1e XPQjardb9tYw1TWbVeSEC94Lu3Vn1KjC1Bzy5yLyP4C7gQMaScihuKMBqzQdBf/zABWn5kpn JPhDXCIqat/FhemhMqAMtBIDqjS1EpGajTKQTQwU9V3/Cljtv65akP9BNtUrRXX5J65zOnAk 8GbcNZ/B8UhgPWAlcDhwDNASYR5nxSV8GceqNMWRoofKQGsxoEpTazGp+aQJAyWhor7XXu+6 Zgr3SEuTQmVUMYp6rx6E4bgLMK9hy4wqePoUthpF+TNwLzAWCMosHFCpORTgpHHG/RhoicxG or1bklDTKAPKQMsYCLUsmaZSBtKVgRK3qq7y3lAo9M/CXrWcLKvSTAbcUMGxrnHPlKXtfm1m Uo0eY+ANeDmH6apYUL3vafg4REdL1LOAzhcDCSrKQCYwoJamTGglLWPzGFjQcWFd78hR4VDe m4Xdq0ZE5zs1L48cjh0pDXMys8q6M3ARshjfSDa0gN4CrADWRbHnptVdgXhZhgBVxOJZ0WNl oBUYUKWpFUjULNKPgZqygm/CvWovl4KCV6T7ou1lcY/y9CullijLGZiO+nG5gHhrUxnC+NnS AGBd5h9tgvRLgHjpjADOl1JpgoGS9tJbQvK+4yuXLjRMg/XeXER368OMYItLBPifjoYQyVni yqQHKoVWRJUcZQD9Q0UZyGIGeizsILV5YVnWlb/qVdbAQGHfmv2wQ9XAqtK8+DWB1pBKTykD mclASUf5DNux7ZJo6VfWyWv3VshdVSJdkGYM1iVKNKnGa0MGuOcehB9b8AfGcoA/KFYBlQDn FNYCVJgTErU0JUSTRspYBhb15M2hsjYGulb2dyT8jLjV264tqp5XBrKEgcdQj4SUpuV1WCi7 Qh5HfCpMKjnMgE4Ez+HGz52qzy3O71P7R+layeEQlUYYKCoq/CdGKO6uKiue3chpDVIGso+B cnkOg3IRoGmTkZHqJbVyDhQmfgmpogxgVFdFGch6BgasNnVmelFh0Tiucp311W1mBYt61+yF /Y53rCr95bZmJtXoykBGMnBde9lPOsqTKHw+5jI1NU1l6WJXDrurUl7KyEpqoZPCgA7PJYVW zTTdGKhdmP9FuE/dtRLGxPBeZTvKgt4V6VbGtilPScgNhbYXt+ZgkcGYrpFVwq/LKHW+k5T/ BciVq3k3ba2IXZZDO7R2zgOWxoLVlwoGsApofr+OchKu9ReoSZt514QlCS73B/SFVicoUWjM 6Zj0ffjdFTIXJ9rZ0+oqA2ppSrwPDEVUPhjzgR5R//1wg8Ib0q6g/BP85wdPwl8E8CsufmYc zO8rHEei4DX4ELbH3OTzCYDh8RiNMJUEGaieH/6PcczXReEejySYJAeilbhcYiBSVjglzSq7 M8ozbR3LdAnS/30d87DJf4Vnc4BWiQsAPgcoMwF+xbYmOQUn3wIwBOpNSH0K7jjgcEAlyQyU QOkp6SQX9uskM9B6j3gKk4HiauSqciPrYz73Qq8IUYUJ4Z8hfOe7V8n0JBdNs89ABlRpWrdG OwbJm5o4ywXsjorLfj8cUyF6Oy58RxzzFytRBuBXf/0xF8ijlAB8YAdxMo5VmsFApPTGM424 /y3oW722F10zctWoSWCASsW+Sci3pVlywvCPAJ+ZdwEx6wQO1iB34xwtTLynrwNeBA4BuLAl 8TtAJQkMlIh0wBdyVzgdZTYemv/GJQZAQeLz9CRTLoOuL5db/7EKCpMRPqv5ZKWF6enF5bLP P8vVEuhxov9+w4AqTb+hpFkBNyD2vQAVmXjhjbg7QKuUFSpRfGjSitRcoZVJZZ0ZKHGrS/Pf iZQWrqsVY51L0tYZFPapu8ibIN/WBRG5GEXgy2wWcGm0OBvBtYtsUtk4F+A+bqXAnUAeQNkN eMzz+ffhrfD/BLwKBCf+816ktWcR8Bxgv4Ji2MkArb1fA3sC9wG0LPFebQdQqCgxPzu/5RP4 7Tn+GPoGmA2cA1ihtawrwBf2/sAzwK7Af4G/AFcCZwOUEQDrRWsUh4Q+AAYBVkbCwz47AbjK BsJl+Y8AvgXIX7x1G0H1ciB8Y4FfgCeA7gDlEuCvAHmZAVwGHA9QSZwIbAc0JlQEWSaWl/wU AxQqgmzPFcALQC+A0tLr+KkT/F+CdhnZUS7HnKVZ+Nr8Vjyde0Ax+goK0+El5bLF9SvlScSp rc/OldH04wF7c8lKORFabnX9OfUoA8pAixkYipRUXGiWpyJEPx8S3wGnA5Tg8ByPxwNn0gPh Q34xsA8PIMH8/BD//3w48b8++YAbA/whDkGFDKdUEmdgVlFRr9WDRT5kuwjXKCrq636WePrM i1nYx30BdWS/lby+NbvCPxfzu9q3cU1o8fse6AfsBvAFvDGwM2AVW/b/5cAewGbAVOAwgEIL 0IOeT+Q0uHzRHwScCawC/gVQ+PLnvYc2l+eBqwHKr8CnAK/3AMCXKRWXrYApAPOkMN7mANOT wy0AB2D4FwDLcQbA9FZ5KIHflnMs/Na6+RH8LGMhQD+F8eqAa4GBwH+AJwDK1sDXwDCAzw1e c0uAQv9XAMt2HsA82gHxwrJSkTkE6Akw7xsByh3AMoDPFypgLvApsANwL/AmEC8sI/k9FNgU IAeXAwMA5kVFsjvAetj0LbkOkicmF4DPkZ3kz1CYyuAaApamTzDpm+2+RkE88hKUEA4KgI4A lb4hANthL+D3AJZpUskEBthW0TZj27EN2ZZsU7Yt25htnbDkJRxTIzbGAB9Q5wMvAy81EuFp hB0FPAzwl24E+BBoiWyLRN3iEv6A40VxYXqYEAODq0y47tDCvnucXl06d2fHdfrj1tlFulf0 kcXt5yeUReZF4osTto8lncISvtd13b+kwYT4vigRX+L8AfAJQOVlJRDf1x9D2EcA5TbgYOBV 4PMo4MgBwJ2AfUkfzkAIf+jwGlQ4Pgb4I6cTYOVGePjSDwOnAtcDVAjeAajABeWX6MFMuHwY U0YCthw3wc80VNKGAC8AvYH+wDSA16DiNxagosVrWCmDh+mZ71+AWQAf6CuAE4DpQFdgHsDn Aa9BuQb4Poqr4G4ELAD6AJRfgQrgHOAToABgXjsBVljOZ6IHTHs/QEWN5X0ciJeTEPAe8Fr0 xAVwBwF/BMjluwCFXLJelu/mXod5rFGOQRmHd5RTocLyWgM8VZaWJVeuKanwyrjG9DwJC9Tr a42kEZQBMMAbUmXdGOAD4m2AD7t44UNob6AzQOXpOYC/4loio5CIeQVhH5otyS/n01SXhu9y jJlc1Kfvg644A/CmqirMa8d2ylbZEkMUqwoLutyKCi6NlH3yIixOIwp61f6hDSv8Aa49GvgY mAGcDlBhiZefAwFUJnYNHFvvXvB8Zg/gfhn118A9C7gYWAr8G6AiZYVKBSUC/ALY69fCH4yH w0ZlbiCUyklx9Jj59gOYX2EU5JrhfCZcCVCJsEJFBt3QE+bDZ8UmwGqAShSVGT5vegNBKQ0c 8Fq8/p+Ab6OgwsU8tgOmAXOAQ4GgWA4YRh6mRk/yhyGVrHgZhAD+aLPCaz0PDAaobFlhmVmX HtGA5l7H5tOoW9JBfg+FaQoUpYcRYQDYm4g+fijmK+2UqMLUaMYaqAw0wUCoiXANbh4DlyP6 8cA2ccn4AP4GoOmdZu+nAZU0YKCwd+3BBb2rh1WtqrjIOM7wkOMc5uDrRscxp6ZB8ZJQBAxD Ot7QSTG2FdjOcaVdYZ89qvMk/Akuhqq3mVB5oIWAL1VabWmpsBYieOulY73PH4riyzheaP0Z EAikxYXCl/7nAI+pbFGpuBmw0tIfMmtL/zYi8LlAReYm4A2AStgY4BXgUYBKjJVgHWkZ6wXQ SkPr0XoAyz8UmAQEpbHyj0SEcBRUEncD+JyihY4WKIZZBQ3eZv+Yo8LEfKywbLzGFKC/DYRL pbECYNtQGiurf6YZ/znkhuG3r50QuHTAiZGfYVk6HsrS1mo1agaRGrXZDKjS1GzKGk3ABxsf inzoxwsVJb4UqoGv4k8245jzFLrGIfiQbUZWGlVCobNCofwpRR07LAIbm+DBy+EOrPGIuSF9 V3bPNoYKeu/CF0sVJsaGUcetYWPeEXWuqXPd0yIL8tpSmT8GXN8L0Br0FkCLBft5vByFgDyg A3A08ClAWR+wStbr8J8E8F7hC30fgMKhofEAFTQqHM8CjV0DwWsVKhp88fMaa5OPEIFK0oXA g8C+wCjgZuB3QLzFaDOEERQqj1RMaBmjteldYCUwGKDi11xFl3lMBGYA5PE4oLl5UAE6EqCQ a/I7EKByRiWsF8Dw/QCGU/iD8T2AvK2zlLST7bB8wLvhsJfn9rAqlaI1zsbXcMNKVnnDi61y nXUuqGaQtQyo0tR6TXs3spoOxD+IxiCMD5B1fTFdjjyWxIF5q7SAgerS0OFS556Jhy5fRDEx UlMk7WgVzC4JhbdAhYIvlKWuqR1RU5Y3qo0ryj68OzAT+ALoCzwDxMsqBPwE/Bw9cXvU3Qnu PVH/Y3Cp/PI+HAd8CFAWA28ApcAHwEjgb0BLhArT/4AJQPsEMqASR2WNSg8VC1qNRgGjga+B oMzGwXMArU8XAP8HUFi/mwDy8zjAtFcDXYBEhTwPAr4DJgOfAFsDVuGEd61Cbh+IxmJbvA6w rGyTCPASQO7fA3ie5b0MaCnXSOoLJmpvggnezzt58o0D5RMdeTnu3StXlMuG16+SB0qCX8PZ ROoqA0lgAP1PRRnIWAYa67+NhTVdwc5zOhcU9/uHEwodD5WiEJaYENxPq+aH9mg6UeadKexd c7s44UtQ8irgx+q6RQfKwl6LklCToGJms28szJ6jy+GzjQGWZwEQL08g4DOAygIVECo/TQmt KMxrFrA6LtIgHBcDP8SFt+SQCsvyZiRkvxwEdAKoaNDyHBRaZC4C9gUGASx/kDeWuwfwC0Dh 8N1Cz9e8f0MQfQ5QC7AsVHbYJ1oqtNjVASviMqCljxxReeL5FsnVRTIwP1+uA3mn4OdoGIRU gpW7qsrlb7f5X+m1KN8EEoUQh32pEGgH0MJJvlinbsAYfDkGRyXdGcB0BBaRFm0aHXjP8ofy KqAS4H3Ie4E/hhISdgoVZSBTGGDv9+6AqBv02zrYMHu8ZnfFwIrICjknv/f8/4Scno8Y4wzG PTZCOr7WVcoPbWiFWnNOaX3WCTm74RFfZ9zaZyJlJ56PZz5fZMm4/4NvEuun25jfcsYXN60f a5MKRCDWJHwATm0iwuwmwlsSzIdvc4T1n5VAAj68ZzYSjwqgVZh4uiUKE9PN4L+otEb/Xmoz i3Pn45hokWAYri9659XoNWfifiyAWwMCH4rUyg23VLY832YUhu3VFBJ+wTbjeho1uQywzZpq T4YnLMl4aCZ8cY2oDCTIQFBZ4i9AHlvX+plVMB6PE5aasj749d99l8Ke006SvK735RVssCXe vl8nnEGaRzTGrTZm5bWRsq73oai875N179sHExkJPqisny7bKRiPcdckL+JkUGFYU9xMPfcj Cv5Ypha+tcp9VXvpVRDyhvTORScpQidxYdB5ojYiJTdVN1D4WuuSieRj+ypd9l9CJbMYsO0W bMsW1YAPLxVlIJ0ZYB+1oKJkwcmn9NPlefptPHg9P93mS9EJ7aXqqbVZNJqfb3an4MOIYh9K fEjRT4sW/dZttYcX8lTJEgY8yxKUJViVzsKdW4yew41zn69x5fqbVrXKcGpzmeKzhD8sOHTM oVEOz3UEODy8HvCqDs+BhQyQ6PDcYSjqMoDDyOUAh+dovaWVm9Zp+/yCd82SrF+ba75qcs6y c5OAZAlfzhQ+/NcmLAvnDvDF+yvAF4VKyxiwipBVkNgOBIdHeK71peqp1s8zt3PkA4lzQXjv 2PvH3hMJP6xym8LsrH1JkQyCWnIpXllnQGEq8pQlIy/VujLyxor6xTvTofJW8Wf/9V6yeBkn 5/mTDrXNrjLwGcM2s88f++xpUS3TRWmiYnEg8H2LauF/nfYp0g5oYfpgsjtwQC30WuAgYDbA ORL/AKip3gA0JVvgBM9zgtlMoD+wM8CvgW4BOOlMJXEG7EPJKkzsr0Q+gHUp9X2bOJVtFzP6 cuGE2hq2W6AkfIjxWBsyQEoueEvaY5uaMCxLRo5FffkjiH1gDJSlG6EstfQ9kAzqWC6+ZK3S xD5MHAfQ6tQJ4FeUnCxeBPDZxGcUn1kqqWOA7UPFiG3DDxv4DqbRgvP2aF2y7cZnjm3PFj13 2LjpILugEGXpUBCU4UbAknkm/K8DVJrWJvsgwrkAPxNmY20JjAdoyt0DuBM4B1BJnAG+UPnw CSpNtOLxBaySWQzwhWIVJt5fFnyA2fsts2qkpW0WAyVUJjrIEbDPnIuesFc0cQ1++zyJHnA7 FqVM5DnbrGuuY+RgH+XLli9lgj9++WLms4gKH4X9mCMdNkyVJrKSOiH/bCO2AcGhN76H6bKt 2Ga2/aziZNsXpxKXVCtNu6NoVwLbAR8CZwEcZrkL+AvQB/g9wErxF8jPwOnAbIDyJnAJgEm7 3gaLJXBZ8ScBK93huRngGGYpQEXmK4Dp2MG3B7YFHgDmAiUAST0D+BY4CagEOI7NG3sbgJ8q UnoALwE7ASz/aQAbgzzeCvwO4DU+BkYBLMMRwDDgbIAvDl7rOmAxcAiwFfAccCnARu0L/BMg V1OA24H3AVqxLgZY9z8BywByMxFoTEYikL+GeD3mfwtAeQt4GjgPcIDLAHLNsn4N2PrDWy+s E9OzvrOB+4BRAB8MNwAsB9vhfoDc09+S6yDZb4Rl5HVYhnygECCPKpnFgG0z9g0+4CwyqxZa 2mYzUFIMi3u+nAWr0pl44vAZzwfEKvx7CE+8f5Ws9qYwNDvfJCdgP7VgX+U7ieALmc/81QCf SRQbXgA/n1EM53NLJXUMsK3YDrQosY343mMbWcWJbcZw245sU9u+dBOWVCtNd6NkVF5mAn8H +OLmS5ZKVDugK3ABUAKMAK4EbgL4IqeQCFaW8fjiHwl8A9CKY4XKCZUeKhlUBh4EaPUZAJwK 0NrzFPAi8DnwR+AUgC//g4DBwCrgDoBKzYfAB8CeAOMx/T+AR4FjgCeAjYEfASqArNOrwD1R /1dwDbAUYLlLAca/BDgcoPI0BuC1me58YD6wDbAfwHyGAe0B8kCF5QDgNoDcHArEy9YIOBA4 CmAneR94A6CCtTnQEbgIOBV4D/g3wLo+CRwHsG5BYZ14zV2BIQC5+xRg2P7AjgDb72XgV2AU 0JLrIFkDiVeY8nG2AChuEEsPMoEBthnvXfZHukHgUCXLGHAwBLcffu6cg5uYz6iwp0YY/BA0 +HG1Sh4v8YdO0r3afHbbfsuXLhWivCjgeP2Z4XxB89nEc/yRR6ikjgH7PKnFJdkehFWcqA/Q H1ScGJ9t22xhA6dK+MLrCQwFPgZOBzoB8VKGgJsAVojWp1kAOyArSSWA8nvgG4DKC4UKzs2e z9/rqHfUfy/cD6N+Oi8Az0SPF8C9H/ga4I3wOBAUKjnUUhcC5dETVG6ejPrfhrtJ1L8h3NlR PxUplpuyA/AWwJc/FRUqTFYeg+ej6MFtcA8GqDRZ5YbXngzwGh0AygrgEoAvHtZ9FEDZFCjy fH4axjsBmA50BeYB2wJUmig3Al8ArPepwPXAKuAdgApdvLCt/gbQ8kecDfABcSZAhWsuQLkX OB4YBVCaex0/VcP/5I7tz7LymoWArSu8KhnCANuMDzT2XbpsU7atShYxUNJBhqNVT8IQHJ8/ A1g1DL/xBTYGT/D7S1Z5z34GZ4LwHWQVJlow7HOILoX9mC9iPpcIvk/5nOJ5GwdelRQwYJUm +3xhnyPYPlZ54jHbkWC8FilObORUCQt6FvAv4HbgeeAGIF74omdnpVBxYMU2AaYCVvaC5zN7 APfLgP8m+B8F5gOfAn8HbNpf4bdCAm04CWSnX5sE07NstK5QGH6E5/OHzbrD3x8YAdwDXAlY BQleT362HrizgMuix3lwabHZGqDSFBQqeiwrhUpOsefzh9+GRf0D4PJXz3UAlczlQLySYetB Dn4BmBeFD4F8z9fw3yAc/hAIGh31M/yrQPhM+HsEjpt7nUBS74XKlyrBBxAfRkHFCYcqGcQA lV37ELMvFtu+dO09n0FV0qKSgWs6ytB8I7/HnobHQlnaIsDKLLTqQ8B/MV+JPz4zUdgv+Q7i c5fvMPZVCsP4vORLmc9MwvZrCF7QrwAAIABJREFUPq9sPHhVUsCAbadgW7G9CLaRffbwmG3J eC165vAFnSqhUvI5sBHAG+sq4GbgBCAotMhY6QlPL6DMBkTdmXA3D4QxTysk5ACgO3AcwBf8 QIBCotZFmHdjQuWG5ekE3ASwXtOBMwBaX6jUWesTvJ4E68m0VIh40z0FUMn6HUDOqABZaar8 QS4Y925gPYC8rAReA4LSVD7BOEH/NBz0CQTsBz/DpgD9Aat8DoX/C8BKc69j01nXvlSt0sT+ SvAFrJJZDLDN2JfZfvblYts3s2qipXVK2sFynYchfSNHQ1GidcnTEvAWWgp6nqvDgpQ3lnvP +xa9mNKEYpadzzD2Uz776VIYzmOCfdn2ae3XIKONhG1i28u2DZVa+qkwWQXKhrFdCaZplrCx UyVUKMYBfMFPAp4F/gTEy2YIIPhC/iPwA8AbkXI88A5AJeAiYAgwB6ByZOUxeKg0vA48ClwD xFtaEJSQkHBrzVlTAjYKh69GAWcAVNqs7AjPKUA/YDZghVYgWsFYtqOBTwEqOt0Alp0Nyvq3 RDZBomcAKkyDgV0BWq+aIzsjMjvatwD5pnL7HtAVIMdDAZaTZfwYqAYOAch9a4qDzKg0WcUp H35CJbMYsO1mXyxsT7atSgYwUMIpAh29ffEOQaMdhJbzf0T5LbgMQ3CvIGxM6Up590H/uZEB tVprEflCZQ35LLbCMPvC5QuY/Tm+TzONzww8KilhgO1iYduH728Lvsusn65tU6ZplqRSaVqM kr0BlAIc0ukOUPGJl9kIeA5gR6RCcSJghVYYvsy/BMYCVKiY35uAlbvgGQNMBGjNwT3sTbaG 02x5FyluA8oSSMlrLgKonMwEfgL6A4MAzn+aCwRlFQ4Yh0oZLTW3A5XAKGA8QEXxc+Ab4B/A KCBRuQcR/wOcCbCDjAauBl4AEpXzEHEFQKXpUeAtgPXig+JWoBx4HHgHmA6wPnT/ByRDrNLE fpHKfpuMuuRinmwzth3BtlRJYwbOwg+Tvh3xpbGRvWFJ2htF3QVqQKEtMt40v8D/hlsnr5RV yAd4yPKllI1iX6rBlyz9hH0mUUGiP6gsqdIEQlIotp3oEmwfulZBsq5tOxsPUZonbdGwg1BE KgpUeOLlMARQkdoXGATMAli5pmQQTqwGFsRFoMVmEEBlhBaQdZEOSMxrkPREhdaYDYCZgLWS BdM+gYPPgNFAZ4CKX1D4K64CoKWIL5kuwBKgOUKOewC/RBP1hLuu8woGIA+WNcgFy7cRwLLG 1wNBLRb2Tb5o+aBmXdgOnQDyRX5f0sUtwUIGSHTh5CNRVN4LVMTZV6hk877i/UlFfE33OU6r JJOBC3Cfdeko2+CGG4Hr7IX5SbvhBuQ95wksSXzZfImw17EA5etptgBltJRJc/gsIihWObIu w+mnBOP5Ifo/1QwElSGrODHM+ulSgvH8kAT/86WUapmdwAVZsZkJxGsqr2VIS7SG8OHeXOHL oTFlKT4fKkZEvMwPBFBBaa7CxOR8IVmFicfrqjAxj7n8FycsH+c3JVPsw8g+oOxDKpnX1Lxb lwG2GRFsy9a9guaWMANXF8uA/LBntd8ZlqSd8QbZGm6BzYCNBEVpKlrrA9fIB5FyGQuTe2s9 U+1lMsW1L1jSYl+6dHlMsW683zup/1LKANvKivXb9mN40G/jNcttC6VpTQX8EScfW1OELDn3 IuoRVGiypFqtWg0+iJqCKk2tSnVKMotXmOLb1j7gUlKYXLlICRXVjrIhFpbcGtajraAYbQ1l iAoSLc8xoSXJyPdohM8dVz6C+2FJRULTEmJ5ZL8v/oXLPhwvjYXFx9Hj5DHQ2HOksbAWlyAd lSYqTtkuVJpUlAFlQBloLQacq4tk/XCBDAsZb922YXh7D4OitDncDvz5Yd/mUJj4c3spFKmv 4PkCStQXlRXyFb5k4TxFlcQZaOxl3FhY4jlqzLRnIN2UprQnTAuoDCgDykBbMXBVO+lTEMZX w443Z3IIyrEhsAkBXaidVy6rHeEg6p0L5WgCFKjxcMfX1Mj4m6u8r4696PpPGVAGEmdAlabE udKYyoAyoAwkjYGz8MVajyLpm58vAzBENgADa/2h6AyAojMQys8Q+AfXK0aNlcLIfJg5foCm 9AMG26Zi0s0PNY5MurW8RXMiG7uChikDOc+AKk053wWUAGVAGUgmAyUcHiuU3nUF0gtDYr0x uasXFKJeUIZ6QwnqBWWoD8IHQOHphaEzf74ev0mFeJYi75/vx1DaYhzOQJoZOD0D6Wbg08Of wuXyQ4m/+j+TqSgDykCSGGiW0lTSUd7ATX2QVxbDjytw20NwE3vuWo5d3OiM50bj46OM6HEs r9+cQ+b8SiEG/9NXxuNXW8zTc73j6DnkWxc8Tz8K64XxnFcGpIO/FiXgcQx+fnW4Yi2ubcNj foSDA4bXenk5OHb9Y8Tnp9O1XpmYHn4U1Ivrnavz8uR57xzO+C6OvbAQjiO+n8cGx2YV8kA+ WASlFp/Z1WI9FKbBpVWUAWUgVQyUcHX+jtKpNiKd88JY9iKE5S8c6YJnC5c36Yobshvcbjim 6x3Tz3A8L4oQ5i8uhsB6ifo9B/+gAPE59Su8c3H/c0jtV1xjLp5Fv8A/E/OOZui8o3r21KMM tAkDzVKaGpTQETwLcEsHpMEBwhM+js+okbT1l4nLtMFh9CAYZv0sLMUe1/uDAV6M6L+mvs8K hNcnDYTV5xsNi/5g9DNtcICgxtiv/+g3Wo5OURcOF2saCeDBSqWxBpXxlS7ju3hA/yYM9eai c1QOqeT5fqaLpmE+9UqcHxbLw1cc69NAOYydYx443+CaCGMcaIlUMn1EFUNeI8yy1AbO2TgM tX4qjlAUsV5C3UwUHAtthWej2RpblwGnVZQBy4BTgrWGqrCmV6idFBW4WNsrT4rq6IalKAzX DeGckfa4J9qjP7aHktIe/bcD7oX26H+cLO2FIcMOON8R4Z1wf3RGnM5I4yk++fXLO9rL+i7i NRB7TBfpK+GU4XpcT64MedNdgPunDDfyApwvc2vl159WSylWyOWPLBVlQBlIUwbsvd3c4nnp SqI6yJSou1nUxQqH3vm+UReLDDnQD0JYlZDhITxBqMOEsGKhd1zdURw8i2iHCkWM70J38I4Z n+H1boHvh5kozHDoIZ6LJ00YD0kvLsN4ntfAQxLPSwkjYhimrTAy8uLjHN08g3A8zMJ4cDF+ GAqJ5yKnvHo/1Bvrh/Unj+lQHqpA9IcZ13N9Ncg/5/jxvOvY8GiYl45hPPbz8N3GwhqPg2xz TGCNRI1pdUNTSF0EL8eu3bpLKA+NHkYT0AUcNHQwzOG5sH+O8bxjxkU8/5wfn37vOBBuzzcW 7oRC3nW9dE7UjzDv2J7jMc7ZMKZpFOgIvCO8c1HXHlvXWyAyEMdrfd5FEKT0XMb1jqNu/HH9 YqBgMOhnGo/exsIZ5uJrdKKuLubnsWkkLBrX9eLCYFtbK5ddeqkMCcvTRY5UF4SkBvd2XT6s xOj0BjckS8v71r8HuFaQ8dYLKkC1Gvpp7eE5fz0h6y9CWBEy8ZQaj4Bk/DP4ccGFOR1ZifKu AC0rPNdfu4hrsi3Bc4TrqS1FvCV4/izBg2cJVktbWuIrTckoleapDCgDKWbAf8qm+KJ6uXVj 4BgobL2hYEHRxEiB5IU6Sh4sPHn4dZ3vvXz4AiqQPPzK9o+pjEGlhGaIdxX8PI9jKJHeeeYR VRJj5xGG930sPdJAYYwdM40TyC9wjJfHb5RAvGT8vBtXAv34Np2NwzyjYXgpxtnz1o1DTZ19 DKCPVaFPVqH/raaLY8+NO65AnyJWIQ4NmKvQtyoQ1wuD5acCP7QqcO+UQ49eEXFlxeoKWXmH v1hs9pGmNVIGlIFmMaBKU7Po0sgpZIBKEpUpDojwU+oO+NcVAV2h5PXA8N3jSxYv8iwZtGrQ okEYbIbl+aNhtI64df45z/ph4yKef86P71lReC4Qbs97blw4LS/1+fFc1MLi5WPPMWwN1pj6 NHiD037mHcNFITxLEI8bhAfjMB7EsxB5nuhxNJzp/GDfpT+6nYln1ao/pp2H5/BHm099HD+C d1xvHaM1LmgtW4MVzbPqRa1+f//nP7GAkLyQ58iqPCgk+VBMgEocr85zpSrkSATwhoFRhBpQ Vo3iRDB8FfFc+jnbLxQ9ron6cVxVIdUwMa0u8bdjiVWW5VdRBpQBZaCVGVClqZUJ1exajYHf KE3ImTO8OLWLk23H1A8x4UAlfRmIKmIwkHrDV8vh2r3nONfH7j0HDVFFGVAGlIH0ZkCHPNK7 fbR0bcDAokWLZOrUqbJ6NbfvU1EGlAFlQBlQBnwGVGnSnqAMRBn47rvvZLPNNpPttttOjj76 aOnatatcf/3168TPTz/9JK+++mqjeXzxxReyySabNHrOBm688cZyzz332EPPraqqko4dOzaZ LyNdfPHFcu211zZIpwfKgDKgDCgDyoAykJ0MUKHnAgwdgV7AEGBrYC/g9wBG51pPSktLTYcO HcwTTzxRn+ns2bNNz549zYMPPlgf1lzPU089ZQ444IBGk0H5MXPnzm30nA287rrrzF577WUP PRdKmFlvvfVMdXV1g/DgwZIlS8zSpUuDQW3mZ1tF24xtxzZkW7JN2bZsY/3xBhJUlAFlIP0Z 0IdV+reRljAFDPz73/+W3XffXU488cT6qw0cOFCeffZZ6d69uxdWUVEhZ555pgwYMECgyMjX X3/thU+aNElOO+00uf3222WDDTaQbbfdViZOnCjTpk2Tq6++Wj7//HO54IILvGPmf/fdd8ue e+4pP//8s1x22WVeHnWYhH755ZcLlDTZYYcdZNSoUV748ccfLx9//LFwyNDKiy++KEcddZQU FBTIO++8I8OHD5fOnTt71rEFC7gEkAiUP3nhhRc8/7x582T//ff3LGdMx7JRmqqPd1L/KQPK gDKgDCgDykDGMJBSS9PBBx9sRo4cuUZrDBQec8QRRxjMdzJPP/20Z+2hRQdKkcnLyzMXXnih +fHHH82RRx5pDjnkEM8SdMcddxgoY4aWLAz/edYsWo7efPNNL93QoUO9a0JpM1tssYXBcJ55 6623THFxsYFS5Z3baqutzEMPPeT5a2pqTLdu3cx7771nfvnlF9OlSxcDxclAqTJ/+tOfzIEH HujFu+iii8w111zj+XfddVevbIwPJc1AqfPCm6qPd7IV/6HHqaUpY247LagyoAwoA8pAJjKQ UqVpxIgRhopLU8KhrnA4bGbNmlUfhcrP448/7ik/VGRqa2u9c5999pnZaKONPH9weI5KE5Wr xYsXe+eobFmlacstt2wwNPjYY4+ZKVOmePFgwapXht5//33Tp08frGxQZ26++eb6cEYsKyuj cmJWrFhhrNJEJS6EJV4xqd3Lq7Ky0txwww2Gyl5T9fEituI/lgngkKoOz4EEFWVAGchcBnR4 LnPbTkveigxwWI0Ts+MFSoe89tprMnPmTCyf5HpDZxxCI7766iuxw2G9evUSKCFecsyNavLL u0GDBgkUrPjLCOZPyaabbloffvLJJ8uwYcO84z/84Q/ywQcfCJQh4dDcscceixXNQwIFziuP TcQytG/fvsFQHvMdPHiwFBX5C2bDguVNEGfaNdXH5qmuMqAMKAPKQIwBLh6oogzkPAOcF/T3 v//dW1QyuMDjLbfc4n1RR4UGViJPUaFiQlm2bJkUFhZ6c4SoxKyL8Cu6+fPn12fx7rvvel/W cf7U+uuvL9tvv733tdzLL79cP1eJX/pNnjy5Pg3nLrFsVACtMN+FCxcK50xRqcPwnjdPa6ed dmqyPjatusqAMqAMKAMNGVi3J33DvPRIGchYBs455xzJz8+XkpISwTCbVw8uFfDSSy95k7xp renXr59guM07h6/ePGWKlqg1CRWtRNZ7OvTQQ7288UWcpzydcsopgvlK9VlzQjjmXHlK2o47 7uiFY96UULmaM2eOd8zy7rvvvg1W9abCxbI///zzXhwM+3mWs5bWp75A6lEGlAFlQBlQBpSB tGGACn3KlhzgFB47F6ldu3beUgNcbuCVV16pn92DITJvEjasTt6E7ptuusk7x7lJsFTVx8PX aaZ///7eMedAMR98XedNBN9www3r4wXnNMFK5E0E79u3r4GiY+666676ePTAWuTNh8LXeA3C Tz/9dIOv6AwsRwZDf2bChAneeTuniQdcooDLKQwZMsS7xvjx4704TdXHO9mK/9COOqcpbW4r LYgyoAysCwPOuiTWtMpAEhmg0tRg7zkcJ30bFegK3vwizvfhMFdwqI51pSWI1iUoN/VLETB8 TcIhsUgk4g2drSkez9GCxbzt/Ki1xed5DustX75cuBBmU+l4fUxA9/IO5tmS+gTTJ+LXbVQS YUnjKAPKQCYwoEpTJrRSbpaxTZSm3KQ6ubVWpSm5/GruyoAykDoGdE5T6rjWKykDyoAyoAwo A8pABjOgSlMGN54WXRlQBpQBZUAZUAZSx4AqTanjWq+UQwxgockGteUXeZyv1JSs7Xxj6Tgf iWs3qSgDyoAyoAykhgFVmlLDs14lhxjgIplc84nCPeO4UCW+mpM99tjDc7EJbz0bazt/0kkn eXvMccFMrsHEZQ/wZZynLHHtJWzr4k0yr89QPcqAMqAMKANJY0CVpqRRqxnnIgP86u7SSy/1 Nt9l/a+88kpvEcnp06d7q4pzvaT//ve/3sreiZxnHOa3atUqb4NdbK0i2LdOHn30UcHSCN5G vNwoWEUZUAaUAWUg+Qyo0pR8jvUKOcQAFZru3bt726yw2tyupHfv3p7ixGNsviujR48WbqdC Wdt5L1LgHxe85EKXH374oRd6xhlnCPbM81b8DkRTrzKgDCgDykASGNBtVJJAqmaZuwxgYUtv vSTLwNFHHy0XX3yxt/bTgQceKHvvvbfss88+9rSs7Xx9xKiH+T/77LPeEB2DevTo4SlM2Ay4 wT508en0WBlQBpQBZWDdGVBL07pzqDkoA/UM/PDDD962JTbg3HPPlXfeecfb/uSKK67w9pE7 /PDDZenSpV6UtZ1npFtvvdVbZJPrHW2zzTZeHrQ2WeF8qeAedDZcXWVAGVAGlIHWZUCVptbl U3PLcQa4Wji2UGnAAieAcw4SN9R9//33hYrV9ddfXx9nbec58ZureRMVFRWeEta5c+f69AMH DpSVK1fWH6tHGVAGlAFlIDkMqNKUHF411xxlgBv02uUGuHVJUVGRzJgxo56NPffcU84880z5 6aefvK/e1nTeJiouLpZu3bp5YPx44Rd43IBXRRlQBpQBZSC5DKjSlFx+NfccY2DLLbcUfilH wUa63jwjft3Gr+oolZWV8t577wnjre28lyCBf7Nnz5bNNtssgZgaRRlQBpQBZWBdGFClaV3Y 07TKQBwDI0aMqFeaeOqhhx6Sr7/+2vuabrvttpNNN91U+AWcXatpbefjsv/NIRe4XLJkiVqa fsOMBigDyoAy0PoM6Ia9rc+p5tg6DFCh59edhUA7oAPQCegCdAPGGGPgpJdwztHmm28uEyZM kE6dWFwRlpNLC5SXl8vw4cMlHA43KPTazjeIHHcwZswY+d///icPP/xw3Jn0OdQNe9OnLbQk yoAysG4MqNK0bvxp6uQxkJFKE+n4z3/+403Mvuyyy5LHTjTnfffdVx577DFvpfCkX6yFF1Cl qYXEaTJlQBlIOwZ0eC7tmkQLlOkM/OlPf5INNtgg6dVYvny5UDHj1ioqyoAyoAwoA8lnQC1N yedYr9AyBpptaeJk61q3TupM1K0/Rli93w34/fBgfPrronkwTZPHOOdi2K3O+Hn4fob5+TOd 9dMNnvf8uAYHF+25xlwO2zGu99fA76djuHc+Gsf6STfPWcFpT2yYHdaMHQvWgfLjOIK/6IHv j4XTx3P88/04xl/ICQFBN+gPyZ133CGyfpdXJM+plLzwaskPrYZbLWGnSkKhaiSOIJsa5FkL t85z6SdcEEw3HD32wkMRMBARE3XrnBoxdTgOA7UR5Ivj6ojU5Udk9YKI3D0d8QOE4EBFGVAG lIGWMKBKU0tYS8c0e+6ZJ4MwB6gdUACEgRDgAPmRsOfWFeRLXg0m1DiYK5TP+UI+jMmv99sw ukwbPG7Mb3ClkDRMzzAnEMbjxtIGw3itpuIZ1EiiZTTI1yBurduxfccOntJCRakWSoyKMtA0 A6YK5xqHkdWxc85q9N0KTESrQJ+rFAn5foa5CHOAULgCHQ/hskocd4XUVqyU278rRx7aCZtu AD2jDGQFA+uiNAXT+v5j8LihLNrTdzcu991lVY607xGS9arx6Ing9dgxJB1qHFld60i4OCRF cJ1ISCLtHCmo8/01xXBr8Dp2kUc+rA61IbzrfVfo1gHhkLghvJCj/rADv4vwEMLr4IcbQpgJ +HneRRjDGcc7H01nw72XPtO5/sveoZ+KQDSMrn3J08+XP+PW+6NKQvwxfgp7cX1lwfqtG1NQ bLqgUuFdownlAyyS9lwXWjvy0B3CsHx4LprfP0ZYvT8U8PvhjN/wvJ8Hw/xzjRx7XQvEo/kZ j9du6GeYn2/QEsP8vLgoJ2+O4LmG1hp0d896Q1sO/prwM421/lg/+wHTWEEUT2wY41Nix1AP YI2KWZ580xSPG7NSxeL5aWJWMlq+fKta0L34kktENljvcSnMWy0FsCwV5NXglq6RgrAL0kBc iAWKKvCN9HF7PxgTvUccfBzgKdFQpqlQOwWoDBR34/u9HwEIs8eO9zEBq5w8ofnOU7acFbgu Vxq1wLEsRxiWgA8t8Vzj0r8Uz5+l4tQukUpZKnd8QcVNRRlQBtKcgdiTNZGCXrvXG3gwHJRI VI2TagaMP5zhDV8EhjKM03C4o8H5JtL4cfzhkgbxA/ky3A6luNGhlWAY/QbhNo7Nx8TlEQwP RYdiMMbimZAqMKqyrCosy1bnwS2U5VXtpDzSXqprOuP40fIV5Z5SZBUkqwykmnm93poZiLbL MYgFpYEKhKdQrIILS45UA+y7ybTSOHLqnoX47rIIqlUR1LIiyXOL0TexUqhT5Lv0A8YUi3Ha QxNtj/7bHlotXDd2LAgTnjf4otPB55EGgGtMR097RSYtlErksQBlWYDrLkCevt9FmODYgWvM r/LjknkyZgqHG1WUAWWgDRjgL7eWiZ0YwdSOE/tp6h1Hf5/an6Q87/nxM9SLC5fHTflh88ZD AnnCtenox9PLCwu63ks5es5TEBgHD2CHyoJ3HSoNDKMLRMOt30vPeAin3+DF7bmBYz7U68+F /Dh8+QfDGIdpbVx7zHhWGXDC/nk7T4NxeK6BIhFVGLww+OkSeXWI5/IamOdRB6WiplaqK2ul bHqtjPHqhktnlcBi6Fkf4pccoDLnWdY6FBZnVYW1MkljwMiosXZoLlkXceSyXbEsRn5nCdd1 whBeJzyy4Dqd8fTpgudRN6ArnkldcT/DBRwunRENE6cdzg9G+GCEx8QzwvEQgQzfpIeR6/Za hDzmIq9fEfYr8p+La82FEX0mng0z5NZPFsUyUJ8yoAy0JgPB27M189W8lIF1ZaAppSmt12la 10pnY/o0sDSlP63n7tlBukZ6icnrhSFLuIT0gtLlu470RiX6Q1HqC+1pzT92jcH8Kmcm4gIy w4NjfpTaqqlyy1e0XKkoA8pACxlQpamFxGmypDOgSlPSKU7NBVRpalWeQ7Bo9cacsP6wTAFh KlID4B8IJWsD+DeAf70mr2jMMpybCvwAq/VUTPucKrWVE1SZapIxPaEMNGBAlaYGdOhBGjGg SlMaNca6FEWVpnVhrwVprxixnuTnQ4GqG4IJ51CiZENYnjaFkrRpkwqVMfNxpXHAeEwDGI/v bsbJbWNnt+DqmkQZyGoGVGnK6ubN6Mqp0pTRzRcrvCpNMS7a3PfXPXtLMZQn1xmGpUKgSMlw KFRbQbHq3EjZFkLR+gL4TJzQ5zLXfBedG9ZIVA1SBnKDAVWacqOdM7GWqjRlYqs1UmZVmhoh Jb2CHLlmF1imCrbGBzhbQ4mC62yLIvaMKya+2jOwRjkfYsL5e7Ki9DMsHMqvH1WUgZxhQJWm nGnqjKuoKk0Z12SNF1iVpsZ5SfvQK0ZsgDVwd4ECtQvKuisAqxTsU1aMwdpSzicYznsPHyW/ Izd+OtGeUlcZyFYGVGnK1pbN/Hqp0pT5bejVQJWmLGnIC3bsJOu12xnDdftiOG9fDO1tCYUq 9g4xMgeWqpdhjXpFPoYyNXYs199SUQayioFYh8+qamllsoABVZqyoBFZBVWasqQh46tx5W49 sB7V3lg1bT8oUAehofsEoixF2OtYP+oZKFDvqgIVYEa9Gc2AKk0Z3XxZXXhVmrKkeVVpypKG XHM1HLl2rx1gZToC0Q6HArVpLLpZDNV5DIbxHpcbP/oiFq4+ZSDzGFClKfPaLFdKrEpTlrS0 Kk1Z0pDNqcaVIzaWcB52I3WOx1DeZrGkZho2KHxE3KrRujZUjBX1ZQ4DqjT5bTUJzm3AU8BY YDDAX0rcG4vCrTy4DUMP4GJgBLAHEBSm5XYtJwE2Pyw8JzcBFLupLrdSodwMjAde4UGc8Fq5 vkeIKk1xnSJTD1VpytSWa6VyX7XbFtiU+URYm/4YGMLj/nlPSq35l9wydnIrXUmzUQaSzgBf TCq/ZQCbcMrVvw32Qp7GfypNwc9xsaO6HAxQcQrK33DAc8S9wKOB45HwU6YAVF6DyHWFibyo KAPKQDYwcMsnkzAsd7lMGzsAVqZDMZGcPxS5Fcxpkud8L9fu+bZct8d+2VBVrUP2M6BKU+Nt TGXnHGCjRk7zV9FUgGP3VvaBhxvJvmsD1FUGlAFlQBkIMMCNxW8a+7rcOPYIidTw2Xo3JotX wPq0P1YyeAfK0yS5es9TZM89qVCpKANpyYAqTY03C3YQl38Adzd+2rMoHR04dxT8zwNUnJor XIn3D3HgwnIqyoAyoAzpPfdmAAAgAElEQVRkJwO3fTpTbvjwQqmpGQDL05WoZCmUp82xWfEo 2Q0/Sq/d/QSEpfv7KTg6YP0ss6LtOLDtEHRb9R5K907ZqpVtZmb/RPwNgSMbSfcMwvYC1vv/ 9s4Fbq7pXOPry00ukhBy1C2ioXGnnFOtCElL06IowhEcJ4TWXYMeIaJIqlp3KkU1EY66q3sd KhFOUPfQoi2JO2ncUhKJyJznP9+8Obtj8pn58n2TfDPP+/v9Z6+99tqX9ay93/XutffMCN5V 2k3w2K45xjYOLWJAczZUY+vkVJ8lwbtjtralAG22pPYkvy3aKTpo/S5R3o7QJ/X4ZuPs4k8e RTFqvbngfcYviazhXz4UnUVs78tK884PcCPGdmP+WaUxfom7lJ675Je2lY+fPfS+Rp5+lt6e 0zflPjtQh/0XBU/r64+I/zuNGfRMGjOY1x6WF6MjjoAIvx8wMmaWPw2ifZhGu9GGS2U0tK20 AjilYwTvIk0RWZuhmSfE98QrgrJTRXNsplb6ZnNWrKN1sp0Dna+DprbX+NFu2bZse7Vo+og/ 0OKLxBaieNT5GeW9KAiSxosw5m8RfPkj7GUleA8SGyjuED2ZKTK+lcarAm3fLnsCvSaloXo5 vP/2/5HaNYzRa56bKO8O/ZTB/Yo3j09nTH1qGVWUjjY6Wzpf0jGNNIeWLce8rfoKhH9hz/ic mI80U9op8pWszBw0Na3XnVrMXeJJJYoxsrSnmCGuEzSCreUViJObKSc8cMdua1sK0GbRftk2 bVu1aPpouXHqJrjZ4vF+sYXPiKCpowpw47VPccEy52vP5/DeU3pgQhq6sYKn3oflg6cG3VTm 2j2hUaeJaeHcUVX+qYIIhCI4IliCGL1gGsuiLM1H2lY9BeJaCN+CryEdfiemtAvLwmK9mP/C qYOmL5QoHasipe5wrlf+TwVD67uK5hoXXa8SK7+vvIobtMR2aiUrgiVO/oVoo6+y2zG1jdbl PKbNaLtwXm3jyCs/yqO1ykPiGvFm0eo81h8jVhHvisGCx25/EM2xnbTS5pkVGa2Kx4WZ7DaY vOFP6HJBOnbQlalHGq0Y5EjN69t2XfdMowednmb948LUODrV2pXDx0AESvhrYFTR/kcitAHD /6wkwv9wyBE4VdzHOmhCvqbtb1p8oSgebXpbeY+ItQWP6pprG2hFHGix9VTGnOLMOpznpOYE j6CJYXzg7hyN+HkI7u67is6Cu3fOa5ycrXoK0D4ERrQNnTe/cfax4BzmxiLaLYImylfssLTO 8m48LpsgGGkaVnSwf9X804KbLMrsIW4QaNIcG6qV0DmMG63aCJqiRudPITg5Po3eRqNznc7T +07f0+jT2Wm1HocoeDpS38a7L4q2wjSCogiY8CuAj2nI5Wrx9G0FFZfxJgs31yvoMPBB0aYc Fdcd8xU1pIMmpEtps8ZJ/nNQJh3Jk5WAYtuhOKMwn91eFDk6EpnpbUpnGzGzyEkpwMkMETDR KQPvkNEx894Hd30YZbg7jTwHTahSPYs2og1gniBoYkpb0WbRfhE4RftqUU3ZaaoN7y8NKlGr eER3pZbtJvYqUabcrOEq+Hy5hdt0ubHTXtLx76pHdEPkES6Q1+yvAOpeve90vX5dfGQa9/Ab rVA/fDN+JBs04V/ogG1tSwFuqGlPLPxO9C1MyzYHTWVL5YJVVqD4xKajBTpkOmA64wiYIh+H xl0g+XGBKGmrggK0F+3A3RxtRKCUDZxoM/KjHWOkKdpZi2rGGF07UVwsXi2qFe8/jhVDBJpM E7ZyFTh98j3p0K021UjTj7TKGF3le6f2K+ykUaef6KHoBa3wx8AROOFT8C0ETHTAtralQLQZ /gbfE1RcCwdNFUvmFaqsQJzkERjhvDhv49yNfDpogiby4+5QSVuVFAgnxGgSwVE2cOIRUow2 ReAUQVOVDq/qu5mkPf5A7CBuz+ydEZE/Cr5ld63g/G6u8Z5Gr6KVGd0jGKtda3yX6efp5O1+ m9q145Hdnrriz07b5f4zDRh0WBo35aEWqnxxwETQhI/p0kLb92aqpwBths+hvwhfFdOKjiI6 nopWcmErUCUFsgETIxgxTM4Ui0d1OLIImAiqHDShTnUtHBBOKRs40YHHqBMBE+0I4byWJmjQ ZpZbo15HCQKkYrtGGZeK3xYvqHB+WonyI5R3RYn82ssaN/U1VWovjTJ9R1e8glD9REG73FT9 vtOkNHfBj9PZ02a1QKWzgRM+xiNNLSDqMtgEI034pfBP9BHNehrRrJWWQYWXx11yAfUT3Nm9 Lug0skZAGh1JNr+10gQLRNMfiWy6tfZXje1G8EN90DPu9HBc4cDICygX6/jclhhVtAhwOedx TBEcMSVwImCKKXnhwKp5jWi3tppU4Kj1Vkg91zpRV78eizaog8x9oDG8U/R/d+P1qj3nY6WG /8Cf4FvwN/hWvmzSvcBUvwguJdqAFb5kvZ0O9R8FGPnmyQT+KG7gyr55WxYdyzd0oBPEBqK5 dp5W5Jsipzd3A0uxHi95s1+Ef1msJagTQ+0/FTQEdrW4X/yGmVYwNCBAOkXsKi4UHNfsTLq1 9q1dVMU4P8N5ReAUwVMEUJHPFAiaYj0lbVVSAKcTgROdFERglB1hIi/yKRPrKWmzAkupwOht +qWGFS6UB9gpv6Vc7ll9z+2YdPoDkyvcMj4kfA2jFARMfEuXoInHovc6aJIKbcAKQdOOOlS+ iUngxEBHvDIQN3D4obKME6PaRtTeW7y+FDtm/UWi1Ff1l2KzX7jqt1TicPFDgfCbi6fEymL7 AodpirV20MS7DDQ0wSPB0UtiXFFas23eIghiGoERU4Km7DzLo6yDJolRZeNcDLg2IYInpnFH F3kspzxTmxVoWQXGDN5NGzxXfDm/4VzuppRbdEIaO3VGyR2NHnSqxkKvSD+fEv1SBE2MaMco 04pK9xQETXc5aJIKbcAKQRNBNEETP3/CYEOMNnFDx00cvqgsa+2giW84HCyI0H8p+O2STcRJ YpgYIxgZ2UVsIa4XxwsqMVCMEAeKIwXGiM7zgm+nEDFOEKuLywXluSCOFVMEI0Ls/wXxA0Fw cZB4RmCHCspivxKM1GDbiVHiX8VkQTnE7iCmiW8LOut7xESxpthdbCQo/x3BOxwETW8IttdP 3Cg4nvniVjFRoAPHRPB3jqDsn8RZ4g+iqTocreU0fE6cKTgRWAdnQRptOYas7awZ9kN73CL+ SzBMSZ1wMGuL+wSB4TtipKCu/ya2EpeK18RPBHU8WDwuWtMiAGJKUBRwXKSZxrIoq6x8HlNb dRTgPMSYwqLC9LNCOqbkx7IoqyybFWhhBfKP7NYcqd91kp9tWFFbX6A/B75EXnNcOmfK7MV7 GzWwd+rY4XXNv50+zQ1JZ06hz8CXdBCdBEET63cXBE0ri9scNEmFNmCFoGlXHSoxwIeC2IE+ kr5vgagoaKLTaS3bQBs+SAwR/yGOEV8RnHhbCoz5nwqChB3FtwURIYaTJcDACExOF5zo14l1 BR08xvyzoq8YK24SXxIEBvuLNQSBzCuC5dhuYpQgiNlHHCb2E9hF4mzxNYE+RwiMY31REED9 u7hNXCy42B4VdADviV4ibIQS54lhgrodJbBNxDhxpZgpjhRvCXSZJNhug2iqDutq+TriZvGQ mCioX6TvUDprlEWrEwTHQiB0tEBH8tGin/i7mCAwlsnh5PdxnKY/E+hxgGA/tElrG7oGnykN nOSfCk54gjfOEy6ALASUpnoaZLUnTZvQNrQRbUWbRftFezKtR1tbld5QdC5ReXxOhxL5rZm1 Umbj2XQmuw0mL/rb/DT2gTPTJ5/2lwfBr3bQN+2OTd0aXtLL4yenHw+gL1Juh+H67CT6aPz6 wXTyQHx/GH44oG2AGzVb21IgbrJpv2hPphVba16ca+ho/kX0Fg+Kb4g5YhWRtSs180Ahg055 Z0FAMq2AJnl7TJ8EXllbXzMDxC6Cbd8oCEzYxp8FUeVIgbM+W0wUGB3/L8U9zMguEHsLRro4 5v5iqjhI9BDYemImCdlQQRCBfU3cLWgALsI3RditSrBNjP3tITgO7Fzx63wqpTs1fUZ8LJ4T G4gVBbakOjQubYye/6GZv4tXRKQJ7rJGAHmfuL2QiU59xQHiYXGvwE4Vb4uo901KXyuwd8R4 8UfBSXiVqIZFJ4vGjFJgTJnHYlqczi/0R1UVyAZCkY7240Cy6UoP7HWt8F3xbKUrFsrjgy4T mzZz/aVZjeuJG6U1xauCQPJbYqY4QbwksF3EYYJ6toahwQSBj+kt7hJviEMy6d2Vrh37+f/i kw9MJw08J7Vv/zMFTt/V6NPY1LnTyHTKIP1kQfrP/69sw6qpXYf70+jt9tCjvMmFfPxLQKcL tralQLRbtGO2z6ioJq3Z+PfrSCaJqQKHcJD4SBTbXzMZM5QekJnPJp/IzhTS62r6giBgCntZ CQIfjE6egAlj313yqcYA6GSlZxU4U1PWwZEdKn4k3hMXiI4Cw2GvmU81BiqrKr2W2FZQv1Hi AZG1BzMzTyndKzOfrQ/B6+/EbME+s7akOmTLlJPuq0LPZwo+rvSNAg0JgsLYH8EbDhWj3mGM Gvy5MIOunWJBlaZ0uARLwP6DhUqb5U+DaB+m0W60YXNtG634YnNX1npcg99bivWbu+qKWvFW cY3gxgm/yE3TIHGKuEJUa4TnSe1rB4FtJbiGCZKyac3WoP30wenpjCk7pUW5waod/VIvBVBn aNrvn2rboBH+hnZ3pBO321v5DSVo90/lPdMWFKDNSrVl5JVdh9Zs/J46ilMFne+R4gCxmyi2 7pmMTZWm0y7X/qSCq4tsPfprnpETDEddyj5UJsdEoARsg9EpHMg0sb4geCPIGicwRoA4Pu4Y x4ofiRPFweKX4kviLJE1AquwryjxSMxoGp1He6WvEZMEWg0RWVtSHbJlykkTMFHPMOo4UKAh wV8YgeHH4uVCRkvtP7bfklM0LIbjNctOg+L2iPO8knbfToUZvWX0lJHaCCguVHptwY3K+eIc 8Zq4X/QVYXcpwUgK/Lc4SkwR64kzBIbP4Dp+U7whRgscKMa+CSQeFzMEviJsMyUeEOx3osAf YFzrl4q3xBNiaxF2mhIcO35pvBgh8B/XCm6kbhHfFWErKEEgRf3ZF9cqxnEAdeJ4MbbNjePT 4iQRtqQ6sK2fi3XFuYXpdZk0+y02fMI94j1xs9hcYPiTOwT+lP0PEthm4rdilPibuFGwDnV5 RRwnlp2NnTIlnT55e3mOQToIbpw/bw0NHVPHdlelH2976OcXOqeeFcBxtJYN1YZ/KT4VXMCP CxxEse2hjA5iRbGneEhgfUSpICu/sPDxhqYzBethOFScwjRmmjCc7D6ic4EJmnIh9xBPiZ5i usCZxDEzyoKzmSheFt8ROLApYmvxpMC5ZO3fNdNRrCS4a7lXFNvKylhF4HwWiQNESxnH8/3C xtj+t8Q6or24QKwmyN9RkI/tKu4TOWZsVmAZKHCR9nm2+JrARx0hsH8VXQXXJIHQB2Jb8RdB ABT2iRJcS5TlfOYa4Iamu9hCYIeLIYJr95tiP3GgwDYVdPjDBcfBtcK28A9/ELeKgQKfMElg PxRzxWbiN+IyEba9EqzDjdU3BPtmu9uIh8Us8S8ibLASswXXK9OrBcb1fLogD9/0VfFdgQ/F n7FdghNsSXVAgy3F6+Jc8WfxX5n0qUoXG/siMGPbfxVXCIz8Z0Vfgf43CerYTeD/8S/DxAZi qkBHjvEXguNYtjZv/vN6MXxlsWRf17nj2en4bX+8bA/Ue1+eFOjQigdzg7aN4yHAeEvgYK4V OJWsfaSZv4guggv4LIF9XZwjcDZNGRfrVeIksYbAqbCvpmycFt4uZoh24hnxAzFH3CneFI+K VcWxIow6/V38TlAvjnst0Vf8XrwmsvaqZihH3dgHAUqx4QAnCoK19wQB32PibDFRLI1tpZUv FbcIjpX94/xoj+mC/M8EQRLLnxQ4vd2FzQosCwU6aqcEEP0FHe1BoocotreVwbVPh3eciGt5 kdIEERjBQWdBB/6uIGAJG6EEnXhcs9zg7SsmCmy0ICCAk8T64t8E1/O5AiMfX9FNENBw7WBs a3I+1fhBnTiuPcU9jVn5gPB+pReK7cR5hXwmH4qTBcuOERxjbBvfQB72ZTFM/E30Em+IrQS+ BitVh8YljTez+IF5YqaI9OtKZ+0rmkG3HcQn4icCn40eA8QuYo64URwldhb48X+IkYJ6U891 xM0CQzPWx98sO+vcabgez9E2pa3wtavUtePIdNw2q6dzpuGTbXWuQIdWrD8X/oaCi+7v4h2B PSy48wi7XolJoqfgYgojH7BRjZPFnw2LU40XIo6on3hZcEFj7GfTfKrxY7omaxfm39N0W8E6 GE4n7DAlzhJdxPORmZlOUXp7gZPCabFPtlds+xcyumq6qng1UyD2G1k/VGJ18bHAAbUXKwkc /ZLq8CMtCzswEppm07dpng4ojLrhjAmUaJ+wg5XAwbJPgieWY9l9MI/jC/ujEn1ixlMr0EIK fKrtHCrOFVyHdMani2Ljms0VMrluFgn8Ch121mZqhuuo2Poq49FMJtdx78x81hfhU/AH6wmu x1kirJ0Sq4ixYoIg+HhI/ELEsXBs2Pviq4J19hYviu0F2+W6C8N3LSzMvK7pbIG/wZ5onOQ/ CXjGiD3EB4IAMWul6pBdXk66rwrNEARMGPs8Q3xbvCDwV2FoiL+h3ugQ9Z6v9J9EGHVbcrAS pVp32qCA6ZCyd9FthX3TcQN6p189+ov0cTRN2Wu7YA0p0KGV67JA23+ujH3g9KAcG6RCOwoc ahjrTo+ZMqc4XBxvKZtZKrMoj0CpVLBUVCw/ZJ8NmIqXxzxOJoygpZSjj+VLM13SMbP/7DEs zT68rhVorgKdtOI0sb7YTJwkxolhImvdMzN01KuJtzN5X5SkE19L0MFj/cXD+VTjR3T4maz8 jcb/KCM7EruG5rlu2P93BDdI+4hJYh1BwPW/ghGY28S3xC3iVIEP21IcJrLGNsJ6KcFNFAFW saHNygKt5ojbRdZK1SG7vJw0gRH6cgz4pY6C+k0W3OgRAMZ+0PBKgcWNV+Pc8vY56mu99GOX V6RcQ6fUkNM5p2nStKGd6leYzy3qrFp01uO7FRSed0ntG1ZKw7bYP13+OO1oq1MFWjto+iJZ b1aBcgKK7Ha44ztW3JfNdNoKWIGaUKCHavGkYERnurhO/EAU28bKAIKfA8Tz4j2B7SsIbpqy O7SQ9aYKRkJ2EReJpoxA4UTRR+C3homfiK8IggXWZ7sTxGjByA9B0+mCgOZIcbAIG6LEFoK6 Zm/gNtM8PCtGiCmiVBCygfKvFQRM6woel/1OtITtrY1MEdRzhthL0BYHih3F1WKm2FPcINYW BG/TxFZi+bYz/8hN6ZlNHGQ7LaN/XEHwtGBF0UOsJFYRtjpVgJNiWdrNzdj53c1Yx6tYASvQ NhTgUdSd4k3xqFhVcJNUbDOVcb1gBITgZD8Rdo0S3xALIqPE9CrlEVgRrBDYML1HNGWPaOFF 4q/iJdFN7C+wCwXBwzOCUbDLBHXBeJz3PXGpWCgI8PC9/QQBz2iRtac0w7YY1aGz3kmUsouV +SsxQhBUTRIni5vE0hr6fFtw7Bwfmo4TjOoTOGFjBeVOEmsIgsMFwmYFalaB7LtBNVtJV8wK WIE2p0BfHTGjygQYxbarMgikdhB9BSMhOfFFto0KELhsWijYXlNGRwhcCNLKNQK5NQXHlg0S eFTWV/DIb74oZYxcMELEPmeKJR03vnldwUgPgdaSDI16C8phPEoj0Glp66QNUu9inQgcCf5e FgSftWLtVBEC2yWNNN3Q1JfuakWEWqhH4X3+oarLu+IDwbXHuTpXcJ1yfcUjZiWbNk4KmxWw AlZgeVNgZhkHhKOjsy7HvqRCR4mZmcKMzvDOTqXGCFKMImXX5UVvaMpw0oxGfZERTJVTt3kq FwET22yNgIntEhwWB0zkM/I0nYTNCtSDAg6a6qGVXUcrUFsKvKjqXFlhlXjUNVn8tsL1XNwK WAErsFgBB02LpXDCCliBNqIAQRNUYq+p8GWVrOCyVsAKNK3ARx99lLp00RcL27dPn332WZo3 b15acUVew6td47mtzQpYAStgBayAFWijCrz22mv62amG1KtXr7TKKqukbt26pQ033DDdfvvt LVqjtdZaKz377LP5bR599NFpo402Sm+99Va67bbbUr9+/dL111/fovvzxqyAFbACVsAKWIHl XwEGFHj5vbtYTfCy+1fFYLGX0Hvgy4+9+uqrvAOXmz9/fv6gNOqTO+OMM3IKonKffvppix3o K6+8sngfGlHKvfjii/ltDx8+PDd27NgW209LbghdCm1G29GGtCVtStvSxhUNHlVUWBu3WQEr YAWsgBWwAsuxAu3atUsDBgxYfIQvvPBC2m+//dJFF12UBg0alM+/++678+k+ffqk/fffP82e 3fjdhnPPPTddcsklaejQoWnNNddM++yzT/rkk0/y6zC6xKgW5efOnZufnnPOOemOO+5IV1xx Rbr66qsX79MJK2AFrIAVsAJWoD4UaJMjTZdffnluwoQJOQUyuY033jg3bty4/KDNE088kWNk aPDgwbm77rort2jRovxyPb7LvfPOOzkFVLnRo0fnyx577LG5nj175m688cbcAw88kOvbt29u 0qRJ+WUKonLTp0/PMbLVuXPn3GOPPZabNWtW7vvf/37utNNOy73//vstOUjUItvS6dqiI01+ Ebw+HIBraQWsgBWwAjWuwL333psYZeKF7Dlz5qSnn346KUDK15rRohtuuCH/zhOjROPHj08D Bw5MCxYsSOutt1565BF+u7XR9t5777TnnnvmZ3bffffESFXW1l577fw7VAqo0qqrrpq6d++e evfunVZaiR9Mr21z0FTb7evaWQErYAWsQJ0ocNVVV6VOnXhNR7/cqMBoiy22SA8++GA+qCHA 4SVxjG+8Pf744+mQQw5JH374YVpjjTXyQU9+oT6YD+OlcrZla1TA7zT5TLACVsAKWAErUGMK dO3aNREoPfPM539LlUDqrLPOSnfeeWf+22/HHHNMfuQoJGC0ylZaAStTWhfnWgErYAWsgBVo Uwp8/PHH+VEhvWeUD4oIjnbaaafP1YHHbZtvvnn+ZwIWLlyYrrvuOr4O+Llyzvi8Ag6aPq+J c6yAFbACVsAKtDkF+J0mHqfxe0p8k23ixIn595WKK8I342bOnJm22mqrtMkmm+TfbXrqqafS rbfeWlzU80UKNBTNe9YKWAErYAWsQL0rwIAC7/zW9B/2vvTSS2mdddZJHTp0yL84zvtQ+lZc TbW9/7C3pprTlbECVsAKWAErsGwU4Fe8w3r06BFJT5tQwI/nmhDHi6yAFbACVsAKWAErEAo4 aAolPLUCVsAKWAErYAWsQBMKOGhqQhwvsgJWwApYAStgBaxAKOCgKZTw1ApYAStgBaxADSnA f8Txcrf+QiX/rTr+S05/k5L/QUuq+fWvfz2/jB+95J0mftTy+OOPT/rD3/yvivfv3z/xG05Z GzJkSNp3332zWU5bAStgBayAFbACdawAAwr8tHZ3sZrgjemvisFiL9Ei/4vW2hvhP+VGjRq1 eDf8N9z666+fO++88/J5W2+9dU6/Ir54uf52JacgK/f73/8+n6e/Vsl17NgxN3ny5Pz8pZde mlt99dVz77777uJ1lvcEbVVoM9qONqQtaVPaljauaPCoosLauM0KWAErYAWsgBVogwrw33CM EikIKnn0G264Yf6/5Apf008KqtIJJ5yQhg8fnp577rn8KNSvf/3rxO9B1av5v+fqteVdbytg BayAFagrBfhLFX79m0d0YfxqOL8KPn/+/HTfffflfxhz8GAGZRrt1FNPzf/dCgHUsGHDSv7C eJSth6lHmuqhlV1HK2AFrIAVqEsFzjzzzPz/yjF6tOWWW6Y+ffr80ztJ06dPT/fcc0+6//77 04wZM9IHH3yQ+NHLMN6J2mGHHfJ/z7LzzjtHtqdWwApYAStgBayAFcgrUDPvNGlUKTd79uw8 8+bN+6dXkIrfaWIh5Y844ojF5RRU5bp06ZI75JBDcvoD4Jz+327xsraQUGv6nSZf1FbAClgB K2AFrMAXK6CAJ/HtOCjnL1I22mijxGM8jG/RHXzwwenwww9P48ePTz179kxjxoz54p3WcAk/ nqvhxnXVrIAVsAJWwAo0pQDvMs2dOzdpBCndcsstSd+sW/ze0vnnn59mzZqVTjvttNS+fft0 ySWXpAsvvDA9+eSTTW2yppc5aKrp5nXlrIAVsAJWwAosWYERI0bkf8OJ33LiN5l23HHHNHLk yPx7TYwqXXzxxfnlbGGbbbZJBxxwQNKjuvwo1JK3WrtLGmq3aq6ZFbACVsAKWIFmKcCAAt8u X0F0FSsK/tF2JbGKuEHv82hiW94VKPx8wlAd57viAzFHfCTmivlioVgkyjKPNJUlkwtZAStg BayAFbAC9a6Ag6Z6PwNcfytgBayAFbACVqAsBRw0lSWTC1kBK2AFrIAVsAL1roCDpno/A1x/ K2AFrIAVsAJWoCwFHDSVJZMLWQErYAWsgBWwAvWugIOmej8DXH8rYAWsgBWwAlagLAUcNJUl kwtZAStgBayAFbAC9a6Ag6Z6PwNcfytgBayAFbACVqAsBRw0lSWTC1kBK2AFrIAVsAL1roCD pno/A1x/K2AFrIAVsAJWoCwFHDSVJZMLWQErYAWsgBWwAvWugIOmej8DXH8rYAWsgBWwAlag LAUcNJUlkwtZAStgBayAFbAC9a6Ag6Z6PwNcfytgBayAFbACVqAsBRw0lSWTC1kBK2AFrIAV sAL1roCDpno/A1x/K2AFrIAVsAJWoCwFHDSVJZMLWQErYAWsgBWwAvWugIOmej8DXH8rYAWs gBWwAlagLAUcNDEMNaoAAAQdSURBVJUlkwtZAStgBayAFbAC9a6Ag6Z6PwNcfytgBayAFbAC VqAsBRw0lSWTC1kBK2AFrIAVsAL1roCDpno/A1x/K2AFrIAVKFYgp4wlsai4sOeXewVosyW1 J/llm4OmsqVyQStgBayAFahDBbKdLZ2vg6a2dxJEu2Xbslm1cNDULNm8khWwAlbACtSBAtlO Njrez+qg3rVWRdos2i/bphXXs0PFa3gFK2AFrIAVsAL1pQAdLh0vLBS5BpmmtuVfAYIk2iza j7ZstjloarZ0XtEKWAErYAVqXAE63BihoNP9tMA+mvYUPUQ30VV0Fh0F/aqf4kiEKhptRGBE +3wi5oqPxRzxoYh2ow2jPWnbis1BU8WSeQUrYAWsgBWoAwXiMQ6dbIww0THPF3TMnUR7gVFm gYg8B02oUj2LNqINYJ4gaGJKW9FmtF2MOFE+2lfJ8s1BU/lauaQVsAJWwArUhwLRoTKNDpnA iQ6ZDpjOOAKmyCdgYqSJfD+6kwhVNNqJdmBEiTYiUMoGTrQZ+ZSBbNDEumWbg6aypXJBK2AF rIAVqDMFskETnS4BEf1m9J0RMNFBEzSRzyiTR5okQhWNIAgYSaKdsoETj+pitCkCpwiatKgy i4avbC2XtgJWwApYAStQ2wpkAyZGMAiECJoiIIpHdQRLETDF8iijRbYqKBBBE0FsNnCKR6kE tQRMxe82VTTKRD0cNKGCzQpYAStgBazA5xUoDpzisVuMatAp80guHssRLEGUU9JWBQWinWgX AqcIjpjGozmmzGcfz2m2MnPQVJleLm0FrIAVsAL1oUB0xARAdLQRCJHPPMTjOqYxykS5KKuk rQoK0CbRXtE28dJ3doQp8mJkinUqMgdNFcnlwlbAClgBK1AnCtChEvzQwYZFxxwjTdlgKUaY HDSFWtWb0i5BBEQRPDGNEabIizZlnYrMQVNFcrmwFbACVsAK1JEC0almO9nolAmSCJoIkrIB E/J4pAkVqmfRTtnAiTRBEu0V02i7KFfxEbphK5bMK1gBK2AFrEAdKZAdOYrgKKYRMCFHtlwd ybNcVTUbDBEgxXykmWKR3zhXwaeDpgrEclErYAWsgBWoWwWyQVFxOkRxnxpKLJspwVBYpLMB UjYd5SqauoErksuFrYAVsAJWwArkFSjVf5bKs1zVUyACpeweS+VllzttBayAFbACVsAKWAEr YAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AF rIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayA FbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFWhLCvwfGvhth2gnyQgA AAAASUVORK5CYII= --------------050403010308000002090704 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example-2.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example-2.png" iVBORw0KGgoAAAANSUhEUgAAAlIAAAEwCAYAAAB8C5+/AAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB3xVRfr97nupkADS Cd0C9t4rKnZdu65l7et/7bq69tXY12269l7QtWHvvZe1oICAiCAgEkIJLYXk5b07/3PufZPc PJOQhJRXvi+/kyl37tyZM/PunDd33lwRNWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFl QBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaU AWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQ BpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlIEOYsDpoHzTItu8ItdFRZSj tGjNukqY6pJQqC6UQR7tz2nZ2Bnbn9OyNbVSKclAVkqWuvMK7ayarzqq8+ju+CvlDzaZ3KDa nzu+i3XqFTK8P3cq13oxZaApBjLym3lTZGi8MqAMKAPKgDKgDCgDrWFAhVRr2NK0yoAyoAwo A8qAMqAMBBhQIRUgQ73KgDKgDCgDyoAyoAy0hgEVUq1hS9MqA8qAMqAMKAPKgDIQYECFVIAM 9SoDyoAyoAwoA8qAMtAaBlRItYYtTasMKAPKgDKgDCgDykCAARVSATLUqwwoA8qAMqAMKAPK QGsYUCHVGrY0rTKgDCgDyoAyoAwoAwEGVEgFyFCvMqAMKAPKgDKgDCgDrWFAhVRr2NK0yoAy oAwoA8qAMqAMBBhQIRUgQ73KgDKgDCgDyoAyoAy0hgEVUq1hS9MqA8qAMqAMKAPKgDIQYECF VIAM9SoDyoAyoAwoA8qAMtAaBlRItYYtTasMKAPKgDKgDCgDykCAARVSATLSybtgoZFVq0xK VSkSSa3yphS5KV5Y7c8p3oBafGUgjRlQIZUkjXvKOUbyB9dj3a2N/PlKI9GoLy6qIIq6DzVy 4pkNxcZrbxvZfp/6uHseNrLjvkb2PVJko51EDj3ByMLF9ceD1V1vm/rr8doD1jey39FGfi1p PH3w3Pb2ly01MnRTEWM6/9rtXRfNT0T7s/Zn/RwoA5nCgAqpJGnpCZNEnnpAZNV8R1bM9v1v vCfy99v9Ak6aItK9m8iLb4gsXVYvNr6dLLIlBAjt3Y+MPP+qyCtPiEz62JGpn4nMXyDyyJP+ 8eD/RUsomERKpvrX5HUnf4LzcJ0HHgum7Bz/NxNFNt9ExHGczrmgXqVDGdD+rP25QzuYZq4M JBEDKqSSoDHKK4zMmFUviHJyHNl6c0eOx6zSex/5BaRg2m9PkU02EHny+fpCc8DaajM/fM3f RfZBmj69fTGSn+/I3/4qsteY+vTW9y3OW2ekyFq96oXLgH6ODB0sMqTIT7UEs0SnnmuEs2P7 HGlk5s/1Au6pF4xstqt/7Mob6uOfe8XIVnsY6T/ayAmYPaus8o/deIuBQDNy/J+M3I1Zs5oa IxddZWTjnY0cfaqRdz6sr4cto7qpyYD2Z+3PqdlztdTKQNsYUCHVNt7a9azvvhfp21sgYupF DS+QnyeSk+tfisJnC8w8nXKcyMOYcbL2HWek4kJq8CCRf2AGiwKFs1PV1Ub22NXBjFXDfHku BRhnsrguiSgpNZj9MrJ8hcjvD/NzPxjXGjFM5K3xvoD704V+/DMvGrnunyjHHZjtulPkrodE vplo5NMvjdx4i8i4uxB+X+SHGSL3j/PPeeNdkf/cJ7LZxnjceIDIWReLzJojcu+/RQb0F7nz wXoh6Z+h/1OVAe3P2p9Tte9quZUBZaCdGcgrcrFkp+Ptlrtdc9Cxv73WeZe75oIr/PjNdnXN R5+5ZmW5a/qs65ovJ7hm3nzX9BjhmkjET7NipWtuv981O+zjmvzBrhmysWv+++xv82WNDjvR NaxfEDxn4vd++lffcs1Rp9Sf++1k1wzb1DXRqGuGboKyfF5/7K6HXPPzHNcc8HvXvPtRffxl 17nmTxe6prbWNT1HuubN9/xjc3/186io9MM//uSXg3l0tLG+7dxNUiY77c/1/Uv7c8p0Wy2o MpD0DOiMVBI0UXCdky1OLGbkzfdE/nC0SEWlkZ9+9mdzCgscOfJgf1aK5/FRX3a2P+PUo9CR s09z5PM3HZn+pcjO23N2yubY0OUM16tYO7XkJx8/fIGZoX4i/33WT/e3/4h89LnI2lsaD787 1p85+uwrzJLliOyCvK2dcbIjyzCTNfsXkT12sbEiK8tFOEs2Hdfo1wePHffwy3kn1oIdh8eW 3bv54VzMuvXqKTJy+G9nzupzU1+qMKD9WftzqvRVLacy0B4MqJBqDxbXMA8+ZuNju6CNe1qk RyHiN3GEj0r4iK1nD19o8PHe+JcgdLCY3D7W4y/33vmwfrJlGB4T/uEo//FgMF/6+RivdJHI tlv6YoaCZsQwR3baTiQry0/Na76OMkz/n48puNYHuOZPs0QGDahfFM5fBH78uZGJSD+gb318 ba0vBE86RsR7/Bio30QsaKdos/bCa/pYz3KRDq72Z+3P6dCPtQ7KQEsZUCHVUqY6KN3yFUZ+ nlMvpDj7dNdDRm7A2qGHbvMvytkj+8s8xmyzhYPZG/y67nEs0I4LFEqs9z720/M/F/zeNw4z P0fUx1kf81t3bRHObgWtdKHIeojH4zWINswwzeXskyOli0W221u8BfGMX4TwsuVGOGt2xkUi K8pFuuEXhSU4n/G0h/4rsjtmp4YU+UKQv8izVtBdZBrWT7l4yjZ/ARef60Jzy02qu9qftT+n eh/W8isDrWUgPv/Q2tM0fXsxwNka2uht+d94sz277SjyMoTIhqN9oUPhs0VAiDAlZ6X+fGX9 jNR1lwt+JYftEV7HL+YwM1RdIzJ2N5Gr/sLUDY2PXhLzY4o58wS/svNnla74M391J/LPO4yU LRW58a/+7Nh6axu55W48UtzZf9R3wF4iB+3j4DGekX/f5e9dxTR8XPfw7f51OVt18bn1ZTj3 jyIH/0Hk869EKKqG4PGfnVmrT6W+VGRA+7P251Tst1pmZWBNGGg4JbEmOaXhuVycy/2VUsW4 kzm3Uei91m9/AdiWOiwuwyNAzDKNXtefmQrm8ct84wmgUKieH85Q8fpc7zRoQH188Dzr58zF 4iX+zFhn7h3FjUerSwKFtgXKAFf7s/bnDOjmWkVloNMZaH606/TiJNcFU23gSS72krM0KqT0 I5+cPbNtpcrk/tw2xvQsZaD9GQi1f5aaozKgDCgDyoAyoAwoA5nBgAqpzGhnraUyoAwoA8qA MqAMdAADKqQ6gFTNUhlQBhoywO0w+GvQzjLu6k9YW7Gy3m/j1FUGlAFloD0YUCHVHixqHsqA MtAsA2tjz7IF+OFCRxnf+/j5175Yuvx6vgfSfwXRm+8Z2RTHuB2HmjKgDCgDHcGAbn/QEaxq nsqAMlDHAH/hye0wigZ23EL3J+7zf10691fjvd9xLrYM6YaXdv/pQiPXXML3O3bctesqqh5l QBnISAZ0RioJmp2bcO53tJFHnzSy7V5GNt7ZyIef1j+KGP+Skb0PN7LeNkZOO88IH5PQrvk7 v2kbOeoU/zUup2Pvp6Yen8yYaeQPZ/jpDjrWyLeT/Tw+/sLImX8xUnyzkQ13NHLSWQY7qRvZ 8xAjo3C9cU/VlyNIFfNjmQdtaOTY043M+cVPN2u2kd8dh72sRhts4mlk0pQ1u07wmupPTQa4 D9oobKFxyjnYMmNjI/seZYQ74tNuvMXIA48ZOf5P3MjS3+T10mv9WSR+Fu571E/Hfr3HwUZe ftPIjvsaGb2dkSef94/xZdncfHbKDyKHHM8NZfnZgHg6gf2ce6GJVGFrkKBxq5A/X2lk2KZG djnAz5fH+Tjwkmv8zwlfj8Qy0Xj93XH9J57z0/Ocr741ws/cOlv5nxtuMKumDCgDyoAyEGCg s17y+sn//JcMX3qta2bPdc1FV7lm0138F6zOmu2anfd3zRdfu2bOL67ZYAfXfPipf2zrPV2z 7V6u+ewr1zz2jP/iX77IONFc3OH3Otw1j493zcLFrjnzL64551I/3U23uqbfKNfcP841b3/g l2On/fxr8KXD9Cda6SLXDN/MNeOecs3Mn5H3Ya5hWr48eeOdXfPMi65ZUuaai4tds8sBbb9O 4nXbI8w2DTRxRnk7qz8nttNfb3RN/9GuefBx13z6pWs22sk1V97g9wv2bfaZv9/umgULXXPb ff6LrufMc83Lb/ov3mb/nTHT75un/9k1fMn1CWe4ZreD6vsW+3N5hWtOPdc1f7naNeyjT7/g Gr7sm3000Y4+1TWnned6n7fr/umaUdv6afiScObF8/l5KByOzx3KwuuTP352+MLw7fZ2Te91 XPPok/7LxHmM6TrbMrk/Z9SHVyurDKQqA5018HDw4IBijQMFb+C06fDbgaCk1BdY73yIjUJX uab7UNdM+9FPF436N/qypa6Z+6trpk73UVnlmpXlrvn4Cz9ddbVrzrvcH6yY/1GnuIYDCY1C iHX+6DM/TEFEAZZoZ1/imnMvq4//6HN/0Hv4CdeccVF9/Nff+QMoz2/LdRKv2x7hTB54Oqs/ J7bT/ke7pvjm+n7BLwoUQrW1ruk50jVvvld/7INPXFOFPkvx9O5Hrhmwvn+MomirPVwTi/lh 9s19jvT9FEUP/df3s7++/o7vv/cRX1gllodfREZs7hp+ZmgU/fxCQfE0ahvX1NT48TxGgcXP G6+/xRi/XIw/8uT6zwA/N92GuGYx8ulsy+T+nKrjipY7/RjQNVJJ0KZ8rcbhB9UXhO+uG9Tf Dy/B61luu1fkf9/gsUiR/747vrduynTuXi6ywSh/7cfM2SL9+nBXc8d75DZ5qn/+D1+Itz7l 9XfEeywYwsPc6mqRS8/zj/P1LZee7/un/ch344nsuqOfJx+VbLy+f8z+x0AhL78h8tQDNgbp d3C8Rx8b7STyX5TVWjnqUTTQD7X2OjYPdVOfAb6k+pE76+vhoHux707/ye+z++zh9zdoJ2E/ vuIGkV9L/B36N93IP4957LuHiN1Jnzvor7+ef4yfn0vQn9k3JyGdfa+j9yqkTeuva30vvC5y xO9EwmH/un16O97n4cobjBx5cP0u/syvotLvw+9/IsLXIdld+Kfis3LhWX6O/Nzws9cX+agp A8pA5jGga6SSoM15w+fLgq09+ZzI/rhpl5Ry/RMEEN5LN2uCyD+uFRk8yL9hU5hsvbk9Q7y1 IHYA+fQ1vEgYAxIxYpgDAYVBAy395dsikz7iQOEPNkuXYa0KXtNixdJ3yDP4Dr7G3sm3YiVe WoxzBkNwWeO6lcVl/kuOB8YFII89+4rI6SeKtOU6Nm91U5uB2XO5DQGFRr1YevlNkVOxlokC KPgy7keeFHn0KZFxeGfj3EmO7Ilf3m2+sV9/9s2tAv2d/X8LHGPfWrAI73gc7fe//Lz61xNR fNnPRJBFijB+jqxNmMQXh2M9FfIcOMDGinwA8bThKP+dl8HrcyuFX34V2XRDPy3L0th16nNS nzKgDKQzAxhe1bqSAS40542dLwymTf/JyDMvipx8rMjzr4rstK3IXmMc72XCFESbBQaWoOjh zdwOStnZDsSSjwULsXD9M5ErL+Q78By56GqRefPx0mEMAjyHIorpaRwsggOCN1jhGz0Xt7/+ jkEZ8OsriDD+AutHzCbQuBj9BZSzezfmI8Jv5zQOTPwWf9LvW34d/0z9n04MTMBC85oIhBF+ TccZp9vvF9lmC5GRw53f9LfHnxE56zSRdUY6EDFG7nqovj8G+zf5YV/dAn2T8RtCRLG/B/tv JGK8Ga/N4jNaX07AbNfPxqO2ZyH670x/BuvXEoNF8CJr9cILtNGHOUvGmSj2+X9B0NlZJ/tZ YAac9eL7J/Pxq0AaBVjws+hF6j9lQBnIGAZUSHVxU/Nb81DM7nCfmx32MXLwcXiU9zd8293I kW23FPnia5Gxh2Jm6lSRg/YRmTCRQsh4A4gVTqwCv90HRZCtFl8ezIFmlwNFdjvIeI/aCrqL vPg6zsG1g+cEZwh4jXI81uDjk8nTxLs+X/XLwePPZ+DXUZgl46+qnobo+ydmyrp3c+QcDIIH QQDyF3+/w4zDrTf46Vt6HVtmddOHAc5q7rMHHv8eAMGzI2YpXxa54Uq/fp442aS+rntgBuqS YnxxOAy/jnuej5jRTzG7OneewSM9keFDfeHCl2nzkTf7tde34l8ugvnx0duwIRBH3f1zTjxL 5BuIOtq5p/vl2GQXPOI7GTO911BIOXL2H0U4G7wVyrv5GAD57runU3/9IX5eVsR5meFfUGTZ OHWVAWUgcxjw7wyZU99W1ZQLOVfN71iKbr8f2w1gsHngPxww+Ciufh0GC8ufbZdh0Bg62C/H oiXYWqBv68vEGaLhQ/11IXw0kZfLmaXW52MJLFtqvBmoHoUN85i/wF9Xsu7I+jUo9pxkcDP5 Ja+d0Z+bamPOZi5dVt+Pm0rHGVQK/cICR6JRIyvL/XV/TaVva3xNDT5XKE/i3lacIZ49lzNm 9SKsrdfojPMyuT93Br96DWWgJQw0HAVbckYGpemMgYd762yzpcgZJ2tTdEbXyuSBpzP6c2e0 oV6jnoFM7s/1LKhPGehaBrK69vJ69Z23F9l9Z+VBGVAGlAFlQBlQBlKRARVSXdxqpxynM1Fd 3AR6eWVAGVAGlAFloM0MYAmnmjKgDCgDyoAyoAwoA8pAWxhQIdUW1vQcZUAZUAaUAWVAGVAG wIAKKe0GyoAyoAwoA8qAMqAMtJEBFVJtJE5PUwaUAWVAGVAGlAFlQIWU9gFlQBlQBpQBZUAZ UAbayID+aq+NxOlpHccAN0WcvwDvGgRWYENGvji2EqioAirErFjpRFZWSJQlyM+VUF6ehPPz TBZeXRPi62v4Gpv+/bATNna25u7Wg/D+NPuy2Y4rteasDDTOgPbnxnlJ09jGfobdWFyaVj8p q+W/G6ph0RqLa5iiFSEVUq0gS5O2DwN8xcdPP4vMxDsGZ86RGHaSXoWXwEZLSiWElx/nxmLi 5OdLWW62zMdrz1a4rqyMxswKvLNtGV6Au8xxTAWwUowTNo7kiiu5dLNCodysHLd7dljy8nJD I/Fut7WrIzIoUiPd+vc1q4YOcWKoAd6qpqYMtB8D2p/bj8sUzIkiyQqlRL+tjj1uw+p2LgNB 0WT9dBvzt6lkKqTaRJuetDoGYjG8JHa2yJQf+IJYx53yg6n6YYYTnTPP5EP4RPO7yS9GnGnL V7jfScyUmJCZb1x3fqS6ar4sX2t5xeou0MjxSCNxftS8/Plu/+ElC0PDXTFLmkymB5SBJhjQ /twEMZkbHRRNXCLDsHWtn+wE0zGs1vkMBEWTi8vbsPXTZTvZ+FaXkCerNcGAvlKjCWISovn+ v8lTfdGEl9RWfjdJorPn4T3GeVKWnSOTy8udCdWR2HTjmhnRVatmSHmPsoQsNNgJDGh/bhnJ 2p9bxlMGp7LiiC7Fk0U47qdrj9m0iPLi6Kp1DgMURjQrkKxw4pMJ+q1Lvz1m0yKq5aYzUi3n SlOCgTmYR5o4ReTbyU70i69N5eRpkl0b8TrksggevcVi7p0x406qDS2ZUvlTEVY1qSkDyctA U/05P09+wouNv6pcZSbEXHey9ufkbcMuKJkVRxRQFE0Wy+HnMbXkZ4CCics8KKYIGsUUzQow P9SC/yqkWkBSJibB+iKZMUs80TRhohP54hupmjrd5IdCUokF3d+Xr3Q/jsTMhEh15FtZ2m2e yDPh3KIj3nKMs05tac79mciZ1jl5GWhtf16WvFXRknUtA1YoWRHFMZTIBhyDRZ1qyc8AfnzE dsRPk6QWsG3KglNUMdyqhlQhReoy3CIRI9N+9EXTNxOl+n/fSA1EVLe8XCnLypKJy1a4Hxvj TqiRVd9KSY8m1hgdFaspX3l0XkHBhJyB0W8ipVnPZjitWv0uYqB9+nMXFV4vm+wMcJANPsrj GIrfCXuDcrKXXcvXkIE8BK2IonCysI/5GqZuJqRCqhlyeKi8wkhhgeV6NYlT4HDZUn890ySs afp6olMxYaJxfy2RbgXdZT5q+c2yFebTmLjfRmuXf1c+tx82H2iFYe1TLC9ySDg7692cgTU/ REpzcRW1ZGJA+3MytYaWJUUZsGKKj/Q4E8WZDQ7KaqnFgG0zCii7Tso+3mtVTVRINUPXgH7m ocEbO8dttpGpPvQAp3C/sSa0wajUEFXcu+aHGSLTgWkznNpvJ5sqLAjPqqyScGGB/FhT7XxR WRH7OhZ2J9aWzJ1aKevVNENFiw/VLs6ZiLnSvi0+QRN2GgPanzuNar1Q+jKQKKIopDgjlZ++ VU7bmrHNKJz4OC8opFotplJDFXRlOxaVdMuN9d+jsGf4EOPK7/LyTLeD9nFCEFX5o9cVWWcE HpBndQ2NtbVGsP+SzMEKpbkAthqITJziVP0402RjI8ucwu7OXEfMlGUrzTcmar53nNrJ1aX5 c7qSTr12FzOg/bmLG0Avn+IM2FkoiifOaHSLowDul7pGCiykgMU3aN4OReVOO/xRFFENcBcd rpuyC9DhXb11jQJYfbmSNkXOoJoNwk7WAb3Wcg6I1sr6VVXSd3CRVG2ygSObbyIFG442oVHr CB4H4icBPUV6FOIhrLeureVV4sLYMqx2LVsqsoTAZgH0ly4SF7NMVdjMMvpriZO1fLnJ795N lmKLgV+wz82Py5fLd3jM+4NjaqdVL8ybgyu3asFcy0vYkpTGyR4Y+0NYzC/VpdkftuQMTdP5 DCRbf+6WL0trasXJyZH/VZSbj5KnP3d+2+gVk44BjpdWSPFxHmc0KKRwl/eAtaRdeMtFIdRa xkB8TN4Vqbl8haCQWgXwyYwVUi1uTBVSYG3N7Kfc7H7DN3CyQxvmZjmbYD3VttiJe2Q0JoXY ibugtlZyMTjUYA1Sbc8e4kJYuREMFFG84CQWc6Q2ahy6EEIO9JOsXCk5VaskB7+Mq8rJlhVY 7L0UjbQIO3uXVlaGfo7WxmZjcAGic6pLX5knclSrlPOa1bWVZw8s75cX6v6tK+7ZkZKsl1p5 tibvEga6tj/nDTr8elR7cPWC8AldUn29qDLQNAMcL7kcho/z7GxUd/gppPhT+ndUSIGFFLC4 kNoLReWWFRRSlYCdlaKQ4ivIVEiBhCSx4pD0uKBXbl7uWm44tBbeaVIQhW7CX9QJmSh+/xF1 YnE3aqI12ZFlUvJvzD8Vt/o5bZJUuEExsgdFtg5L1huuU7tLpCR3eoODGkhBBjquP+f2q17P yc75orq2amNZXFCaguRokdObASuk7JoozkbxkR6ePXhC6nUVUqnRAeJCan+UlkJqBWAf8XFW io/3VEiBBLUkYiBvYPQkEwpdXhMp20qWtPKXgElUDy1KxzKQO8h9A18C36lZEP53x15Jc1cG 2sRAopCiiOJsFIXUWsDLKqTAQgpYXEj9DkVdBlBIcVaKYqpNQor7YagpAx3KQHVp1iMSiRyY E+4xokMvpJmnLAN5A1aNxMPtcTULQrekbCW04JnCAAWVRXBPqUypf7rUk+vdbPvZ9qTbauPz XjVloMMZqFmSh40Y1JSBxhmoXpiPdX9CqCkDqcBAcOC1g3EqlFvLWM+AbbdgW9YfbYWPGakp A53EwDfZ2QMj20jP5ZwGV1MGlAFlIJUYCA64iX4dS1OpJf2yss0S2zEYbnGNtPFbTJUmXHMG tq7F7yDCed16zMDC4nXXPD/NIeUZ6FtZlDfI/VT6VwxI+bpoBZQBZSAjGVAhlZHN3nWVrl2Y 8z8j5krJynlJBpTyp8NqGcxAbnb+Xa6Y12RRwcIMpkGrrgwoAynMgAqpFG68VC06fpV1r3HM //LC/R9O1TpoudecgdxBtftgYn3jyILp/1rz3DQHZUAZUAa6hgEVUl3De8ZfNVLy3OnGNR9k DardJePJyEgCpuaIE75DTOxskY24b4uaMqAMKAMpyYD+ai8lmy0dCn1UrKZU7k6HmmgdWs9A bv91hromekztgpxvWn+2nqEMKAPKQPIwoEIqedpCS6IMZAwDNYvyZmVMZbWiyoAykNYM6KO9 tG7e1Khc7sDYmfjl1tfYRojvr1JTBpQBZUAZUAZShgEVUinTVOlb0JrS8F14Ncj0vEHDHkjf WmrNyADWxO2KV8F8L/JTrjKiDCgDykA6MKBCKh1aMQ3qUL3glz8ax9kwd1DsgjSojlahUQY+ yApL+B68CuZKkfVqGk2ikcqAMqAMpBgDKqRSrMHSt7gjq2uiVftho9m9sosiW6ZvPTO3ZrmD dj0XtZ8bKcl6KXNZ0JorA8pAujGgi83TrUVTuT7YlBHTFPunchW07E0w0K9iIN64frmpjezQ RAqNVgaUAWUgJRnQGamUbDYttDKQYgy4oXB1tGqjmsV5P6VYybW4ykDKMHD88cdLTk6OFBQU SPfu3WXw4MFy/vnny4oVK9q1Drfddpvgi5F88skn7ZpvqmamQipVWy7Ny51TFLtE10ulUSOX dZuvr4FJo/bUqiQtAxdddJFUVFRIZWWlTJ06VV5//XV5+OH2fYnE448/Lttuu608+eSTSctD ZxZMhVRnsq3XajEDEVl4O77ynIytEc5q8UmaMDkZWGtpTxHsZK6mDCgDncpAr1695JhjjpEP PvjAu25JSYkX5kzV3nvvLe+9954XP3nyZDn55JPl5ptvlrXXXlu22mormTRpUqNl/fHHH2X+ /Plyyy23yPjx4yUajdal22+//WTcuHGy3XbbeULrww8/lDPPPFOGDBkihx12mFRVVdWlTSeP Cql0as10qktJUZUTqzkY08fFWUW1O6VT1TKpLhTCufm9XtDXwGRSq2tdk4UBiqGnn35aKHBo d9xxhwwaNEi+/fZbOeGEE+Tss88WY4w3e8VZJgqtN998U4YPHy5XXokf1zZi//3vf+Woo46S HXbYQfLz8+Xdd9+tS/X999/LfffdJ4jKJPUAACAASURBVLfeeqtsscUWMnbsWC/Nq6++KhRg LIuaMqAMdDIDuUW1e2OzzgXSt7Koky+tl1tTBopW9kXbLc4ZWLPhmmal5ysDScAAJx44s1oI DADWAbYAdgeOAKBJutaOO+44w3JYhEIhs9dee5nly5d7Bfv0009NeXm5cV3XfPfdd166lStX ms8//9z06dPHYHbJS/fZZ5+Z9dZbr9HKjBw50nz55ZfesfPOO89AkNWlw0yXgRDzwlg/ZbBe y7seI7BWy1x66aV1abvSE+eHbca2YxuyLdmmbFu2casmmfRXe2BMLXkZqCnJflvkm2EifcLJ W0otWWMM5JruNxkxj0VKc6c1dlzjlAFloP0Z4OJyO5vEBed5efUvjOBjuEMOOUQgomTjjTdu cPEBAwZIOOzfZrlYfdWqVQ2OMwCBJbNnz5Y//elP3mLzsrIyWbZsmVRXV9ddh4/xaFz0PmzY MG/hO8NZWVlSW1tLb9qZCqm0a9J0rNDW/PSl5ycwHZsLdcoeGNnGEefA6tqyUWlaRa2WMpCU DPBxG2aXflO2WCwmxx57rNx0003y9ttvSyQS8R672YSYvbLeJl0+/jvppJPktNNOq0uDWTBv QTvXQNFakk/dyWniUSGVJg2Z/tX4Jjtv4ObHuSY2IbIwF68YUUtmBmpLF06plZlDMXNevxI1 mQusZVMG0pwBzhxxBunAAw/0xM5jjz3WqhpTeD3zzDPeGqptttmm7txDDz3U+/WeFVJ1BzLI s3oJmkFkaFWTmYGta00s+lkolP1+9oDIdslcUi0bGRiK5wIqorQvKAPJwkDfvn292SQuAicm TpwoFETcLqEl9sYbb0jPnj29c4LpKaRee+01wdqrYHRG+Z2Mqq1WNuUZyB0QPdAJh+7B5o5b 6b5Eydicz4Rz+h+8UWTRop98MZWMZdQyKQNtYoATD3yKwxdudwMKgB5AL4DP0sZjATWc5LYF CxZ4m3X26NFD+LgPC9EbfRSY3LVYs9JxM1HYkUAZsBxYCVQA3J+B7wHlTLoLtMh0RqpFNGmi ZGGgZmHWq/jByf154W7PYhF6drKUS8vhM5BbdPhtTlbW6SqitEcoA8nJALc/oIiicXF5Y+up krPkyVsqFVLJ2zZasiYYiJSGr4mZ6IU5AzYZ3UQSje4CBrL7RTZ3jHN4TWX5X7vg8sl4ycko 1LHxgn0Idy7AmQxrnNngFEZf4AbgIyDRnkDE4/FIm9/FCEfiiMElbPhq+H8HeD9tT3B/+zMs JFBTBpSBNWNAhdSa8adndxEDtaU5X2HR+ZQuurxethEGwtlZd4rjXikrei1r5LBG+Y+BrmiC CL5rY2egf+A497M5AKCYCtrfEeAx4k7g4UD4GvhpUwE+vwginwfUlAFloH0ZUCHVvnxqbp3K wE+5OQNqsBnKPB0gOpX3314sZ2D0KEyBVFWXZD3w26MaE2eAAugMYL1GGOGXAu63dUjg2J7w c9uPdwJx6lUGlIEkY0CFVJI1iBanNQysVyOh8Hp5RYN/FOyi3ZozNW37MhApzXqmpiS0V/vm mna5zUON/gnc3kTNOPN0eOAYN+bBWsA27aGG9xvK7xOwFcJqGc7A8ccf722WyU03uWEn37vH TTxXrFjhMbP99tt7m2hy7RTXUhUVFXm/7OPCdG7SOXr0aMGO5g1Y3Geffbx3+DWIzKCACqkM aux0rGpkQdYLeDHDuDxTgAHnmXA61lHrlFYM/Au1WRc4tJFaPYW43YG1APblgwE+8muLMY/T E7BTWzLSc9KPAW55UFFR4b1jb+rUqd6Gmg8/zCfEvt1zzz3enlN4fYxw24Pbb7/de6ceN/vk S4nvvvtu4QuJaXy3Ht+xd+edfMqcmaZCKjPbPa1qXb3guqvwWKk6d9DhfHSi1pkM9F1cmDsw inU8U7leR231DPCn1fw6fwsQXHjOM2cDE4CDAK6XYtqPgbbYHJy0RwJua0tGek56M9CrVy9v NumDDz5otKIbbLCBcA+q+JYBst1228lf/vIXOfnkk2XKlCnebNUDDzwgvXv3bvT8TIhUIZUJ rZz2dSx2axbMPxRbuCzPLopsmfbVTaIK5ub0eQnrmUeIbMRfjam1jIHXkIxroi5vJDlnoPh4 jzNWTwP4jqCmDHQcA5MmTZKnn35a9ttvv7qL4IXD8sgjj8i9994rfAUM35+3++6cLPXt6quv 9jbnpKg6+uijZf/997eHMtLVV8RkZLOnY6WHroqUynXpWLNkrRMXmKNsvWtKn7snWcuYxOU6 H2X7rpHyPYO4G4EVALcxaKvx0WBjUwTLEK/irK2spsl5fN8eQeO78fbcc88Ga5wmT54sfKzn uq73kmLuWj5r1ixZf/31vXP4QuKxY8cKRdgBB/CHpZltOiOV2e2vtVcG2sbAgNLuuAH/Kyax s0SO4j5Gaq1jYCaSN/aorRTx/wMqAD7ma6txxCtrBIVtzVDPSx8GuLh8yZIlHiorK72XGPP1 L9bOOuss7/15nKn65ptvvBmnO+64wx721kTddddd8sc//lEuuOACqaqqqjuWiR4VUpnY6mle 55yBsatzB7nP4Ys399BR6wAGcsP9Tga/D0VLsj/rgOzTJctNUZEn4pUZA9durBmPEu4pxT66 xEbE3bFwRyfEMRjMzx4+F57TbCDuvgyX+TaGlQlpNZiBDHDROH+VR+Tl5a2WgQ033NCbfWJC /nrv1FNPlTPPPNNbdE4BdtVVV602j3ROoEIqnVs3Q+sWKX3uegwhvfIGuXxEotYBDNSUhO+o Lglf3QFZa5bKgDLQxQzU1NR4s0ycrXrhhRfklltuqVsHdeutt8qiRYvkmmuu8V4xw5mp2267 Tb799tsuLrVePt0Y4LdJrkPIBvrF/XfDDdrxCLwfj5gB9+zgQfj5NaEc+B0QzO9LhO3rIHgN bthnwxvDz2+9jE/EOMRljhWu7AMhNQfreI7InEprTZUBZaADGeDEA3+dysejA4B1gC2A3QHe Z/DO4uQ3LB43l112WZMFxQLyBmPH0KFDzbnnnmuqq6vNzJkzTbdu3cwrr7zS4PxTTjnFbLnl liYajTaIT9YA2yreZmw7tiHbkm3KtmUb6yQTSOhqCwofK6Q4fR/cEC8opK7BMSuqbNkPgmcp wEYN5meP010A7B2MgJ9C6uqEuIwM5vatHg0x9UnegOq1M5KADqh0bv/qdbIHRk/EfYiPjdSU gUxiIC2EVLKKm84sFzptuwopVV2ddxu4FpfijmWNDUBPIn5XgKLL2mHwPA9wtqm1xk6S8Vaz JO/H6gWhXaoX5v2c8WS0CwGz85xwzrthY+ahG2sfaxdOOzwTfhHbABgG6P2+w+nWC2QiA1mZ WOkuqvP9uC6+ycvJwEMJZZiO8PfAwcADANuFM1JHA22xTXASXw8RtPcQWByMUL8y0BoG8oqG XYovcl9VL8x+v4Xn/Yp03JyGfbs97V5kdhcwKZ5pLtwH437r8PjnAI9dAOwGzAJuAuYDtFEA fnXovfvuA7j/Alygufx2xfHTgaDxc81fLv4F2CxwYAL8t8TD/GwfCzD/h4G3gaDxGL9I/ScQ 2VT5mGR1+W2KNPzyxp9T/QwMAXYAngJuBLjZp5oyoAy0AwMqpNqBxBZmwRst10G9CLzQyDlP Io6zUBRSvFlzJoo397YYHyH2STjxB4QzVEgVh/KK/nq165qpfCdcAi8abAEDeQNXjcAs1DlY J7FZC5LbJDvCU2oD7eDyywXxR+CJQH5rw8/1gVcG4ubG/f+AuzUAEeg9WudnaiOAYom/bnsX 4K/nrgEoZC4GmstvDI4vB94ErFEc0SiorgcqGIDZuu8G/z0Ar0Mx9zjAL0mfAxsChwIUexQ5 1grgaap8zeXH8/cEzgTIUyXANvsOWAvgubcCZwBqyoAyoAwkLQOjUTIDBBeb58RL+yjcO4Hj gffjcXSGAdVAT+AOgDc7a8H8bBzdBcDewQj4eZO+KiFOgwPK++cVufNyB0S5eF+tlQzkFMUu zhkU5YDfmO2KyDcACnUK1V4A7UWAizh3BtifOeODx4Jevx8B19rr8KxvA3H3drj8LATtcgRu AVYCFATWDoSHM76JFkYEv5AMDRxYBP9ewOHA/wLxzK8M4OOvpvJj8nFA4meO8Q7Az2Nj9jQi Lwwc4Ofblnd/+FmnbwDGW2uufM3lxy/HXwFsgz4A8z0buAnglymW80MgD6DxXnEmwDYoAdhO zINWBDwJzAfeBijQaJztehi4BPgZmABsBjRlFKnTgYkA29Aa+8wJwJcAyzwGuAv4FeCyhm5A orFNbwYWATznJIDGdrseYB1YXopq1pXWluv4Zzb8z2vkAIXAAGAdYAtgd+AIoDOX+ei11oAB tlW8zdh2bEO2JduUbcs2Zlu32FqVuMW5asLmGLgEB48BtkxI9AvCXwMc6A8BeANTay8GFhYu irnRw5xQ6EEuQm+vbDMln0hJ+O/eC6Ibr/DtiP4nsC3Ae8pZAG1rgINhb+AcYDlAUTUD4KBn jV8gXBuIuxyY8hPibkT4AmBpQvy6CPNG+AnAwdVefxj8FcA8wNpMeEYBPIcDuzXOFLGcfYGm 8mNaXoeDP899E9gGoA0CosCzwPfAPcBaAI3nJF5rPe+IL2BYpw/iYes0V77m8mPdfgTI9e+B l4E7gF8BChYOIOSPdaUxPXmlOKHA3BvYH6BRgC0AtgTGAcyH4qQ7cDxAobUvMBe4HmjMOEjt BxwGHA2cCVjRtQn8pwPnA98B7wKrgAMBfkaZPtHYtrzmTsBVAIUXuWK++wDbAXsAxwEnArS2 XMc/U/8rAy1gIKsFaTRJ+zJQiux40/kb8GlC1k8ifDXA9Qu86bXVuuFEe6O0edTCU24DmejW luZ8HR4QvURycl6Svou3kSX9MpqPduoD2cinP8CB72PgFKAHkGi233MgvxCYDYQACigOsmti I3FyDsCBdX3gOoCfIYqjFUDQfkWAQmAEsBKwxlkMlo3HmsrvARxbG/gCuBegUHkP2BAYARQA LwLLgCuBpwAO7iOAYDnmIcy0zdkIHGyqfDzWVH7r4tgcgHYkQK5pFLlvAA7Ab90lgLVH4fko HuB96QDgZeA1YBJQCUwByK0tN6//ZyAG/BN4BKBtAOR5Pv8cpjsWmAn0BsjzVgDzpbGtyGcY OAng/a8CeBsYBSQa+9ffgZ/i+BNctv1pwH8Acku7EzgGeASgrfY6xd1lIHrkeyCI/cDFPwO2 2D/dujiDWSdGgEe4ISRyylyZfG+VxxWOqGUiA1mZWOkkqPPtKAM/+Ph8NrDxCPFmwG+Ha2KX 4GQiaG8hsG8wIhP91QuzHpJ+i56RWBZv3GqrYSC3qHYvR5zh1SVZFBGNGQX66cC/AfbbZ4Fr gUTjQMoxiMaBmQMUB+ZpgLWT4bEDf1/4PwSiwOvAxUBTdh4O8LPE/N8HKHY4eF8O9AGCxi8Z FFgDgOCxfIRZFw7ETeVHDooAW49P4afoOBDgDBSFgj22GP4vAV6jCmB9rHWHh3w0ZzynqfI1 l9+vOO+QeMYUdLzuEGBn4A7gMuAjIGgUJdZmw2O55vhAYbgFMAUI2kIEKKJoFQD5oz0DUFjS hgKrgKuAw4DlgBVZ8HrG8tIiwC8A86JFgWzP1/DfCAR/CESNi/sZT76t/QxPPxuAu9rrFFdK aXEhyujIjjwv8ebsxSGS8SEGYCtdeeXRKvkvvL28CP2XkQzwg6LW/gz8iCzt55A3VOu3V+IN 295sbBxdpm3s5hHML5h+UDAQ9x8Pl1BrioHF/e3NuqkUGk8GelcNcST8lLg1WzVDCGcDPgfW AzYFKF5uAI4FgsZZEGv94aGQKbURcfcduBQ5tBcADvplwCKgORuDg5zhoHCgUQwMBzgw87oU OHycRRsJTAUGA5sD1kbAMwPgAD4GaCy/nognFxRrNIqmOQDLSFHI8XUaQJsDUPBQSLAcLI+1 EfDYdDYu0Z2LiKbK11x+FDybAJwVvB5gW8wETgU4S/M/4EIgaOTIGs+lSOIXjScAtsHeANuZ dbHmWk+Cy/ODdjsCawHsHyuBV4CgNZVPME3QPx2B4H1vL4QZxzYdAlheR8PPmS5rLb3OozjB E1L2xKbc5TFs+F0pj+G4iqimSMqQeH7w1ZSBDGRgXn72oOgfIBb4rVmtEQby8nL/Ba1we3Vp /pxGDtsoDtjfARQZk4GnAQqXRNsIEQTtDwBnFay4OQb+PgBnDT6OIwKXAyHDHCibsyNx8D/x BH3h8ovEc0AJ8DVwCkA7CuBxCgsO6BwwRwHdgEuBzwFaU/lRSHDg5AwUbRtgK+ANYCDwHkAe KELOBt4CKKZeBE4CeL+loGD57LXgbdSaK19z+ZG3vwOPAD8D+wIsy4fAdsC3AEVk0A5DgF+q C4DDgU8Bip8+wKsARQjbrC1GgUmBTBFFEbsT4ACtsR2QeOv4CeTlWCAXoKCi8FkOsJwsYx7A /NlGvG7rrBwzagazY3iE1+SJRmrKonIGRNSdTabRAxnFAD88aspABjIwdJWJ1c7My8371vSv 3r5mUd6sDCShySrnDazdHZuXb1e9YO6JTSbyDyyB8xpQAvDRCoXK+UCizUHEMwBFBge74wBr T8DDwbLMRrTSheDzhBNnkdYFPgI44NJOAt4HzgQo8CgUosBs4GJgAlABlAJjAFpT+VGkXAbc BtwAbAAwD57/IfAuQFHJOlI0HQLQmH5PYB7QC7gbYNrmrLnyrS6/8ch4MfAiQDE1AxgCjADe BFiOoLH8TJMPTANuBigAHwFYHwrezwGK0n8CjwAttTuQ8B7gNCAGjAOuAJ4DWmpnIeEK4Bvg YYDClfViO94ElAOPAW8DMwHWh+5bQIvtqu5YbB/y+m42pBjFWGO2dIkrx9xe5c1YFjSWQOMy j4GmOkvmMaE1zkgGcgfF/oQvsGfXuIu2k4UDKzOShN9UujiUU/TXi8SNvhYpzZ36m8ONR4xA NAfiHxo5/DvEUVyNBUYAFAkGaG8bhgyrgUUJGYcRXg/g4MrBN2iFCPQDODAnWlP52ZmlX3DC qoSTmF9/gHV0E44xPw76yxLimwuurnyry4/icW2A9bMzgMHrPY7AZwAFDmfTKIiDxlkffi5W AuSRQrAMaI2xX5Bj8kUjP4lt5B1oxb+hSMuyUpxZs+3MsibWw6Zp4J6OpRSDC70ZwgshnTby DmLGCX7OePnG2SkIK3TYmVhYfvDtFZ4Q7YaDFFI9AHLSBxiPX+TDUUt2BhzHkz5Hopzsy8sB 9hkKcH6BqAF4n0j8/CKqcVMh1Tgv6RLLDzhvOPOBxm6i6VLPNaoH9kh6KIRfa1WXhI9eo4z0 5KYYsEJqj6YSaHyXMWCF1N1dVoIuuHAxH+f2kNMwAF6Ey/MeSWnP++Sd5UYeLHDke4y1/RHn iSj8/wwj7SH/KvcGXIosFVLkLEWtvYVUVgfxsAPyfRhYv53zH4z8bgMOD+S7K/z4YtHATkSI 31RGAZwW5rfRD4B/AVZlHgz/sfEwy8ppYVpz+f0FxzfzUvn/JsC5BeAH60E/qu7/XfB9DvDY BcBuwCzgJoAf2KDdiwDT89GEtabK15L8WP/fAyUAr7Ut0B+4BngJUAswECm57rTcoivG5hTV rB8pyZ0eOKTe9mHgR2TzaPtkpbm0MwPPIz87U9TOWSdfdsWcRSqUsyGg/ozScZaM+xlMgWj6 mymXp3Hcm7EsLsA+fg5+venPRD1ZVi4n3+7/qrOjxkwWRS1FGeioTvEt+BjbjpwUIq/jgT8A 6ybkOwZhTs29GYinWOK068vAuwCfyVNE8INzMUBRcw/AeIqbxwHORlD4jAEayw/RTb4CYm0c 2xi4koniNjfu/gPu1sClwFbABwCnkGuBg+L4I9wnAGvNla+5/Hg+Pu/eI4wD4A4CWOdrAYpQ csBHEVY0wqsmUuzWlBQrJ+gKeNR5viumrHZBFtectJdRSBFqyccAhVTaWzFmkJxCOcdgBgqi qa9XYSNfInxjcbm3ng7egLl41BmS8xB5Q/FK+SuO8HgokEK9ykC7MsDZlinAbIDTpDSKCisM roL/TOB1gDMktwJWwO0C/6NA0EYhEBQkPFYEcObnSSDx2fo4xO0NJBpnrf4XiNwN/jKAH4an gQsBa3fAc3880FR+Do4vsCckuAcibM8PHuIz+wgwNBDJ8u8VD18Ol/XCrHGDV140Vb7V5bcD 8vkvQNsP+AQ4CyDHnMmjsAreOD9EmAJ1IjADIGfWeP6HwC8AhaZ/8/G/ybE9xwOc7WJZ84DG jO3GNmO6t4E9AdqmAOMvA2YCzwKbAR8Bc4Fg2yBYZxSDbwFLAdaD59BYr1eBFQDrMgagtfI6 s/PyBqwaCa3r9U/uoYTXynzmZ5We/3MHuc+hjhwkJKuodie+RkcGlHZPz9pqrTKNgXPw3eCa HnLeNYVSCtcQ2CvqEywst/eiJilBOt7Xg8axIwfgF/sBwDrAFsDuwBHAGry0RE/tTAbYVvE2 Y9uxDdmWbFO2LduYbd1ia1XiRnLlo7tTgH2AE4DzgFEAC7MlQGP4RuBmYC9gb2B/gBYDajxf /T9WhvkFrQQBCrZ/ByPjfhLAa3MA5azUNgBtXYBx1mbB0xugIOA5icfWQxytqfw4WEcBDvrf A5zRWgug8Vo87xPgK4DihTYMqADmMRA3CgdyQiMvrBeFQdCYV2PlW11+5I3ChnYJ8EfgTmAE QG54nT6AtR3gOQngTeAK4AEgB3CAfwD/BLYGaGxbGkUhy/0UcAzAx4ZHAo3Z2YhcALAvjAPu AJg3B2qew7Y+FmA/+hj4D0CRxmuzDyUa6zYdoID6CXgQoDGebTICuB54DhgItPI6I6tNOOeg 3KLdvkGT5TuuMwR57Ch9K9n26WpsD3wyynqEJXyn67oX6qL7dG3qzKkXbi5hiKdT+/bw7hO3 4q4zAEPnlyYme2EGapdrK72tKpolBOlebTaBHlQG4gx437zXgA3OOHDtTT+AIoID80ogOFgj 6M2IfEQP7G/AAcDLwOdxwGmzrY0zvwDuBX4PvAdsCIwAWBZr8+GhCuXgOgJYAVij0CmIB5rL j2leBJYBVwIUExQvIwEKkKsAioLrgBqA4i14HQS9vXJYhuZsBA4Gz7PlS4xnHr8CNr914Lci giKAoiMMbAR8COwIcGYoaFcjMDMOCtJdAbbLGcAnAOvF49sD1p6Bh9ehkQ/WOQ/YAKBVAjOA 14BJ8fAUuExneS6H/8+AC7wPDAeeB2glAIXttwzEbRRc9q+xQDVQDFQATLcTcCDA9n4WOAc4 AJgGtOo6NSXh2/IGxbbNG1R0H+ZpfnJwrdysboehMe9EXulom2GNSEVuTq+bULmlkdJPnsfM 1M6hmDMksjDrqXSssNYpvRnA+qYj8Pjueoin0V5NjUzCjf9KFUbp3e5dWbs1FVIcADnTwNmE xcCjwPVAonH2wNpseC62gYDLm/bGQDeAMxUceGmcCaE4asoo5vA58exT/OcAykG1CggKunyE awGKEh7rC1jrDg/FAq2p/O7Bsd6AvRbr+yXAa7CMGHO9Y+SEYuxY4HIgWAYEvfpRYDVnTZVv FU5qLr9fcXwwQI5z4zgCLuN7ApcB5wJBC7bNHBzYCSDfWwP3AzyPwob1tcawNYomthnr/E08 8nO4uwBZAIXWFoBtT3g9W4D/FFE0is6pns//F4WTHQjTOwJgvSiiaOTiOmBvYDoQFM0/I9wf mAa0+Dq5A6MHGInNrq6oPD+3sOCdkH1vmGNOQj5pKKTwCNPBDKOREH7FsjVaw+QO2q0GHTnk isv+q6YMpAwDfFwXDns/5tnGKzS+COFLwlXFFd6Mtb1vp0x9tKCpwwDGijUyDrJXA/2As4E/ AAcDiVYYiNgE/oWBsPXeDM+ZwL8BCg36ieAjLgQbGK+/eyCGH5Y5QBkwFxgBWBsBzwyAg/Qv wHDA2gh4OOg2lx9nUzYArM2Bh4KHA/oYoBdgbTY8LAOvw7pTgFkbCU9QNNj4oNtU+VaX35vI 5BigArgeeA2gIBkPvAQ8DFB0BK1HIMC2KQUogi4BDgAGAf8ByK01K4BsmC754+wXwfPpPgGM A9g/9gGCFgsGWuBnufsDzJfGeh0PkEuWMQRYGw3PF/FAy68TCp0eCmVPzSssoGhcHyJjK+Zh HLxyo2hl33h+aePkDNxxNFq1Gt/ew6jjFmBwO9S5Nua6J2M26sm0qahWJK0ZKO4mWxf3kHcg ot5FRbeBeCrBl4I/4Vd4G0JE8Qt68N6V1lxo5bqGgeDg05YSHImT7gRqgTcAzkgERQOCnh2G /5ydKAAOBz4FaMMAK7y+g/9jgI+CVsT9DFOQNGUUMY8BB8YTbAOXgx/L8gqwIzAK4IzJpQBn SmicJTkJYP35aIgDMo81l99AHH8PoNjiYE7h+BZAMUUeKDZoHHCZ33NACfA1cApAOwrg8ZkM NGNNlW91+X2EPCkwOOt0HzAWeAS4AdgbYB0SjWWiUXyQPwoQika2wyyA7XY04ACtsbWQuA/w KkDh9QegLcby9Qd+AShQjwBoJwIHAfOBOQD7FW0osB7A9myV1ZSEDpaYexpuxMHZLd6Ga/Ok 2yGtyiwVEofCm6KYwUFmqWuiO9eWZj2SCsXXMmY2A8WFsj7WQT3rZMnXuDmNRUdejs/uZSvK Zd2rK+Te4vhWBpnNkta+MxjgILkmxpmOywA+SlkARAB+A+ANOmgVCHA2KB+YBnD2ibY98C/g JQbaYLwer38bQLHAGaOLAV6PoH9C3M+ZljEAjen3BOYBnEm6G+C3GVpT+X2IY0xDwUchRRFm B1fW4TmA4mNdgIKGQo52EvA+wNm13gAH/CjQnDVXvpNwYnP5HY/jVwDvAFOBhcAogNe2vMNb Z7vA9z1AAfI3YDJAXi4EyF134BHgAsCKXnhXa0uQ4hGAfC0FKGwoKv8JPAK01B5DQorARcCV wBMA27oSoJiiXQ8w3eVAEXAtmEuzRAAAIABJREFUQHFvjW0VtGCYArEuXL0w62HpOff5nPzB /5RQ6BjIjFzM2BSICfFaDwUzSXW/45otIY8LMPhUoS4/VscW7yeLBiyGv46PdqpjUKzZLBuL s8fUVQaaZOCKPBmenS1X4YN7IvpvGB2pCp/T26rL5e+4gS1r8kQ9oAx0EAMcRNbUcpDBKIA3 YA7aifY4Ij4DxgE9gRKgvY03/vWAXwDOKgWtEIF+AMVeog1DRDmQ+OFbXX79cc5swAWCxvyq AQ76QQsjwPLNBFYnooLnNVW+luTHth0B9ACmAzVAojFuMMA2XAFQnARtHQTmAiwz86FwZf1a Y4OQmPmuBFhuCtcyoK3GsvYFbD9iPQnOOlLEsl14PcZZC/pt3Grd7IELNgs5/R9CViMhprpX l7/WT8oPYj3SwvKKoh9jedSWxo0+Fik9DjOs42MdVLGgaLJ+uo35O6gImm2qM4BHeEWYH78C veY0fB5z4NbikfSDkahce2NVk1vTtGe1eR/JAnIB3m8KAN4XeU/jF9Xn9BUxYCEFLL6zOSc1 +CV/OcD7Oidf+KWS4yLHPHt/grd5a9MA03yWvzlqhRRnfdSSiwErpDh7lGrGvmv7L4Uv/da1 ftYpmI7hVlpfye0//Xgnq/dd0ZofxkbLNvqqlRkkbfLcQZFXjal4PVLa+64OLmRQNPHLhw1b P12ajfdD+l8ZAAOXd5cBOSHv6cKZEFB5mEFlf3kiGpHi62u85QedxRPvJVZI5cNvhRQnCCik XlAhBRZSwOJC6lAUlUKKkwhWSHEiptVCip2io+15XIAzRWrJx8D1KBIVeKqZFUdWMFFAEZzx sq49ZtOyjvS30pZIzaK+z0vesW9J9ROc6eI30bSwmgU5R8Ur0lF1st/orECywokzX/Rbl+1i xRSLZM+jXy1DGfBmoCCgIJ5Oxyc3H72C/WJ81MjV11c0+nLszmLK9me67Le2L3fW9fU67cOA vf+w/YJt2urc2zCwtPoaeoIy0N4MUCyx71rRRAFFcIpW+zRISAHjjYuPRHgzs7A3NLpqGcpA cZ6MwIO7izC0ncoZqLiAejHqyjXXVXrrULuKGd5bOPnA5QWckbKP9zgjxb78GqD3H5CQAsb7 zwEAxwzOSNnHepyR4hKWVj3a64wZKZRJTRloNwbsjcqKKPZhIhtwdGq93Xju0Iwwtc525FoT /ijAtimvSVHFMG90ahnEQHF32Rxfhy52jPfrZn4xYh8YDwF1HQQUfxCTLMZyUewT7K/sw8TR AEUV1011Byi08gDem3iP4j1LrfMYYPtQELFtuLaXT1/sel2KJ9tubEPbnm2676iQAoNqKcUA B1nekIJCit8QOSirpRYDHGSsiOINzII3tTbd0FKr+lraYgqMAjkEsvpM9ITd44zUYh3Uf9ED bsZu5NOSjKVgH+UAzIGa4LoaDta8F1EE0tiPObth41RIkZXOM/LPNmIbEJxtopCiy7aya6HY flZM2fZFVMtNhVTLudKUycOAFVO8YfHbHkUUB2W11GLAthlvXvYbIV21NGegOF+G4JN7Omaf ToOAGsTqohNU4N/9kCX/Ll7lvY0h2Viwg6ztrxx87UDNQZkDtBVRNp4iivcoxtsvDfCqdQID bCe2A2eeKKQonoJiim3GeNuOvPcE2xjBlpkKqZbxpKmSh4FEEcWbFG9WXLOglloMsM3st8ag kFIxlVrt2NLSOnh8txfmks/Ah/ggnBT2pIXBfncGe/lVyGPFDV/11NJ8OztdUEhxIKZI4lhq x1Mrojho897EeDuLDq9aJzFg7ymccWI7BcUUH/PZWSkrppiebdtqsw3f6hP1BGWgCxkIiine qHRGqgsbYw0uzRkpO61Ol4ONfmtfA0KT8dTiArxD1ZHj8fjuWJRvKMuIR3ccvMZDRt9dXOG9 0YLRqWBBEcWZDrvEwD62Yz/mTAfvS1ZEUWipkAIJnWxWSFHYBsUU28fOTrEfJq6VarWYUiHV yS2rl1sjBjjIWtgbGG9SVkytUeZ6cqczQAHMGxlvbHawse1Lt9U3NJyjlgQMXFkoo7ONHIEN M4+CgNo0UKTZaNX7gQex/mlRID6VvIliin2VxoHbCinOlNtHelZE2XRMq9bxDNh2YrtQTFnB RNc+1qPLMI/rjBRIUMsMBuxAa4UUvwwQHJTVUosBthkff7D9EoVUatVES+tg36et0JIHQiQd DvHEWSjvWw9GM256+EzMyOPXlXuvikplgWwHZ96HOPhaccR4hgn2ZduntV+DjC4ytoltL9s2 FLr0B2eibJydweI5rTI2tpoykGoM8OZlv+XxRmW//aVaPTK9vLbd7GDDNrUDU6Zzk/T1L+bO 3oXei9EPRKPtj5Yb5BXab8FleHz3EuLGl6yUd+7zv/UnfZ1aUEAOsqwhB11rdrBmHAdl9ufE Ps1zfGbgUesUBtguFlYkWUFF185E2TjbpjynVaZCqlV0aeIkY8DOSvGmpX05yRqnBcVJ/Nbe glM0SVcxcDq+sBQVyjYYmvbAjNMeKMeOkAZ1M8EYfX5B3GtuTF4qrZT300g8JVJuB9rgwGsH antPomiiPyigVEglMtmxYdtOdAm2EV0KJ/qta9vOpsOh1pkOPq3jS1MnBwP25mRvVvbmlRyl 01K0lAH91t5Sprog3Tl4XN6rULbEILEzLr871jvtgg9cgZ1X8d55Z+RzxL2KTTNfTbJNMzuS MQ641jgY20GaA7K9N/GeRLNhP6T/u4KBoECyYsq2mXVZrmC6VpVThVSr6NLEScSAvUHR5U3L 3riSqIhalNUwYNst2JarOUUPdxQDV+TL0Oyw7ID8d8CM0w4YVbaAyx9yeMZGgniaBmnwvmvk /Ui5fPg3kWXxw5nm2EGXtHBwplkhRT/jrQX9Nk7dzmOAbWXN+m37MT7ot+la5aqQahVdmriL GeANqSmokOrixmnD5dlmTbUn4+1Nrw1Z6ylNMVDMLx2Fsi42w9wCs0ybQyxtAYFE0dS/wTkG wsDI92iEzx1XPoL7QXGllDZIo4HEQZj9NtEai0tMo+GOY6Cx+0hjcW0ugQqpNlOnJyoDyoAy kNQMOFfkybBwjmwYMrIBSrohRvQNIZ42ges9orMjPEQUVetSiKsv4fkCwuqLqkr58u8i5Uld w+QrXGMDdGNxyVdyLVGbGVAh1Wbq9ERlQBlQBrqegcu7yaCcsKyDub21UZp1gHWB9QnoI744 t8GDprh4mgfBNBGi6ju439XWync3VMtcL63+UwaUgVYxoEKqVXRpYmVAGVAGOo8B/lKuX54U ZWfLUDxeG4qHckMgfoZC/AyHIFoH/pF1YqmxYhlZgOmQHyCyfsCDumlYxPNDrSOTbyqXssaS a5wyoAy0ngEVUq3nTM9QBpQBZWCNGCjmo7VcGRjLkQF4nDYQi8UGQCQNgEAaCGE0AAJpEOKH QgQNwGM3f/0ff+MIw/G6GSb68RhuCdxZOGcWgrNw3ixsZjQjXC4/FIssR5yaMqAMdCADayyk igvlNXzQ9/fKaPiZxq0Ahg+2564m7OLDz3RuPD1+DBIP1+f1m2PInL+OqAcXRfp5ePtCIE/P RZ4x5OYdQ74xL4x0PE4/Cuu78f0kUA9svosN1RCP/Orh5xdDTlFc28bX+xHPc3FOlNdBmii+ PXph+r14Huf5SIMK1R+LeXlGUSbvGI74LsJeXAjhiO9n2CBsKpAH8sFuYtFKAPu18BxcWk0Z UAY6i4FivpqoUHpEI9IzKyw9IXd64PPeC/eWtVCG3vhA9oHbB2G6Xph+xuN+wfcM+pufIbLO 4n7PwT+IIt6nfoV3Hj7/fBz3K64xD/eSX+D/GeuYZuk6pjr21KMMdAkDayykGpTaEdwf8DEP WIMA4lscTsyokXPrLpOQaYNgPBCMs34WlmbDdf5ghJci/s//XhiM8f2B+LpTA3FM5MXH4+Jf LP1zGwQQ1ViL1P0A2T8Ft+s66wXfNQButhSctbiQL8SM7+Km/Zs41Js7ulIwUvj5fp4XP4f5 1Ak7P64+D19M1p0DwVh/jHngeINrIo5poBwpPH3ExSKvEWZZooFjNg1jrZ9iEuIR7xKJ/YyC T8OuwXNAKUSkmjLQHANOMfZCwttJ80PdJC/HlXx8vvJidMOSF4brhnDMSHd8JrqjP3aHcOmO /luAz0J39D8uyPbicJECHC9EfA98PnoiTU+c44mh7LotKRsWBekamA3Txfl8+3wprreQLvKm uxCfn1J8kBfieKkblV9nrJKS8f6XOhxWUwaUgWRkwH6226NsXl7Fcc0wNe5uFHdL4m5R3MUD egeaIdTTD4dwV6GuCeXHwzWF4uD+xPmqUMT4LvSEF0ZhQ4yvc3N8P6aTwoyHNvFcDN5h3Di9 tIzjcV4DN07cQyWMhGFMgYWRkZcex+hmGcTjBhfGzYzpwxApnoucsur8kDzWj1miLJ6H8lAW 0R9mWs/1pZF/zPHTedex8fE47zzGMezn4buNxTWeBtlmmGHWEjXm7ByaQmIRDJi9+/SVUBYa PYwmoAs4aOhgnMNjYf8Y03lhpkU6/5ifnn4vHIi3xxuLd0Ih77reeU7cjzgvbI8xjGM2juc0 CnQEfiK8Y3HXhq3r8BMTSOO1PuNgONNzedwLx93EsCFzNLhBvxdFehuLZ5yLX8YTMUz6Wj9d 00hc/LjrpcXEbDQqF190kawTlifzHKnJCUktPtsxvC/GRac3+ECytPzc+p8B7mVkvP2MclCt hn7OCvGYv9+R9echLg+ZeELHq19H/DP4wiGyAtdeifKuAC0rPNffW4nvlyvDfYRrkZYiXRnu P2W48ZTh7YJLi30h1RGl0jyVAWWgkxnw77KdfFG9XPszcCRE3ECILohPPGWQrFChZGEmKAvf wrO9AYmDUo5k4du4H6ZAg8yEWuT7znwhiDCEpXececSFY/1xxEED1J9P0RkM8xwnkF8gjAHl N8IQA4+fd+PC0E9vz7NpmGc8DgNlwrxf+/OqOaY2A+hj1eiT1eh/q+gi7LkJ4Ur0KaICaTjR WYG+VYm0XhxmiCrx5asSn51yaOsVEVdWrKqUlbf4L1xObYK09MqAMrDGDKiQWmMKNYNOZIDC iQKLD1P4s+4C/OuNiN4Qfv3w6O+xsiWLvRkPzn5w5oMwePmX54/HcRbFjfnHvFkSmxbp/GN+ em+2hccC8fa45ybEc2amLj8eszM1yKPu2GpmberOwajuzQZ56eGPuzzeIB6jvXcOXMbT/Ik6 euLhuPubMJJ4s1o8iXNAngPX+qEq6K9L4yfwwnWzaJy1C86qNTPb5s3+xWcH//Gvf2GDI3ku y5GKLIiUbIgVoArhVVmuVIcciQDeI2QUoRYTXTUoTgSPviKeSz9XD4bi4dq4H+HqSqnBVNSq YsE5pENNGVAGlIEOZECFVAeSq1m3OwO/EVK4AleMcakYF/SOr3s8hYBa8jIQF2eYSPUeffGX ZSuBCoBrhyiAuNYPqlFNGVAGlIHkZkAfjSR3+2jpkoSBxYsXy7Rp02TVKsx7qSkDyoAyoAwo A3EGVEhpV1AGmmFgwoQJstFGG8nWW28thx9+uPTu3VuuvvrqZs5Y/aEZM2bIyy+/3GjCL774 QtZff/1Gj9nIUaNGyR133GGDnltdXS2FhYVN5stEF1xwgfz1r39tcJ4GlAFlQBlQBpQBZSBz GKDw52YQhcAAYB1gC2B34AgAT/baz0pKSkxBQYF5/PHH6zKdM2eO6d+/v7nvvvvq4lrreeKJ J8y+++7b6GkQRGbevHmNHrORV111ldl9991t0HMhzMxaa61lampqGsQHA2VlZWbp0qXBqC7z s63ibca2YxuyLdmmbFu2sX7JAwlqyoAykPwM6M0q+dtIS9hFDPznP/+RXXfdVY477ri6Egwf Plyefvpp6du3rxdXWVkpp512mgwdOlQgbuSrr77y4idPniwnn3yy3HzzzbL22mvLVlttJZMm TZLp06fLFVdcIZ9//rmcc845Xpj533777TJmzBj56aef5OKLL/byiGGR+iWXXCIQbrLtttvK I4884sUfc8wx8vHHHwsfN1p7/vnn5bDDDpOcnBx5++23ZeONN5aePXt6s2gLF3KLIhEIQnnu uec8//z582WfffbxZth4HstGa6o+3kH9pwwoA8qAMqAMKAMpzUCnzkgdcMAB5pprrml21gYi yBxyyCEG66fMk08+6c0KceYHQslkZWWZc8891/z444/m0EMPNQceeKA3Y3TLLbcYCDTDGS88 OvRmvTjD9Prrr3vnjR492rsmhJzZdNNNDR4FmjfeeMPk5+cbCC3v2Oabb27uv/9+z19bW2v6 9Olj3n33XfPLL7+YXr16GYgpA6Fl/u///s/st99+Xrrzzz/fXHnllZ5/p5128srG9BBuBkLP i2+qPt7BdvyHXqgzUin9UdTCKwPKgDKgDKQiA50qpHbeeWdDMdOU8TFZOBw2s2fPrktCQfTY Y495gojiJhqNesc+++wzs95663n+4KM9CikKriVLlnjHKMCskNpss80aPFZ89NFHzdSpU710 mOmqE0jvvfeeGTRoEHZkiJkbbrihLp4JS0tLKVjMihUrjBVSFHYhbEuLhfNeXlVVVebaa681 FIBN1cdL2I7/WCaAj2P10R5IUFMGlIHUZUAf7aVu22nJO5gBPpLj4u9EgxCRV155RX7++Wds 7+R6j934+I348ssvxT5KGzBggECYeKdjrVWTv/gbMWKEQHQlXkawHks22GCDuvgTTjhBNtxw Qy/8+9//Xt5//32BQBI+1jvqqKOwM3tIIOq88tiTWIbu3bs3eAzIfEeOHCl5ef7G35jp8hah 89zm6mPzVFcZUAaUAWWgngFubqimDCgDjTDAdUb/+Mc/uIK9waaUN954o/dLPooczCZ54oVi hbZs2TLJzc311hxR2KyJ8dd7CxYsqMvinXfe8X7Rx/VYw4YNk2222cb7ld6LL75Yt/aJvzCc MmVK3TlcC8WyURRaY76LFi0SrsGi0MOjQW/d1/bbb99kfey56ioDyoAyoAw0ZGDN7vQN89KQ MpBWDJxxxhmSnZ0txcXFgkd0Xt24bcELL7zgLSTnrM7gwYMFj+q8Y/i1nSewOGPVnFF8tWQ/ qoMOOsjLG7/E8wTViSeeKFj/VJc1F51jDZcn3LbbbjsvHuuwhIJr7ty5XpjlHTt2bAMhSBHG sj/77LNeGjwy9GbY2lqfugKpRxlQBpQBZUAZUAaSmgEK/07b/oBLguzapm7dunnbHnDrg5de eqlutRAer3kLvTE75S0av/76671jXOuEGa26dPhVnBkyZIgX5poq5oNf9XmLzdddd926dME1 UphN8habFxUVGYgfc9ttt9WlowezSt76KvwKsEH8KaecYvDrPYMZJoPHhmbixInecbtGigFu l8CtHdZZZx3vGt99952Xpqn6eAfb8R/aUddIJfVHTQunDCgDLWXAaWlCTacMJAEDFFIN3rWH cIe/Igb6wVuvxPVDfETW4N1zKABnjDgLBcFTty3C6rji47RIJOI9dltdWs50MW+73mp16Xmc jwSXL18u3LyzqfN4fSxy9/IO5tmW+gTPb4lfXxHTEpY0jTKgDKQCAyqkUqGVtIyWgS4RUvbi 6rYfAyqk2o9LzUkZUAa6lgFdI9W1/OvVlQFlQBlQBpQBZSCFGVAhlcKNp0VXBpQBZUAZUAaU ga5lQIVU1/KvV88gBrA5ZoPa8peAXP/UlK3ueGPncX0T95ZSUwaUAWVAGegcBlRIdQ7PepUM Z4Abe3JPKhrfkcfNNfFrPdltt908Fy8irmNodcePP/5475163OSTe0RxCwb8Is8TUNwbCq+s 8Ray12WoHmVAGVAGlIEOY0CFVIdRqxkrAz4D/LXfRRdd5L2AmDGXXXaZt/HlzJkzvd3RuZ/T gw8+6O1Q3pLjTMP8KioqvJcM47Uxgvf0ycMPPyzYpsF7GTFflqymDCgDyoAy0PEMqJDqeI71 ChnOAEVO3759vVfIkAq+imXgwIGemGIYLyCWcePGCV8VQ1vdcS9R4B836eTmnB988IEXe+qp pwreEejtXB5Ipl5lQBlQBpSBDmBAXxHTAaRqlspAkAFsxunt52TjDj/8cLngggu8van2228/ 2WOPPWTPPfe0h2V1x+sSxj3M/+mnn/Ye7zGqX79+nojCC5EbvHcv8TwNKwPKgDKgDKw5Azoj teYcag7KQLMM/PDDD94rWWyiM888U95++23v1S6XXnqp9968gw8+WJYuXeolWd1xJrrpppu8 jUG5H9OWW27p5cFZKWtcfxV8556NV1cZUAaUAWWgfRlQIdW+fGpuysBvGOCu53g9TIN4LjLn mia+VPi9994Tiq2rr766Ls3qjnNxOXclJyorKz1h1rNnz7rzhw8fLitXrqwLq0cZUAaUAWWg YxhQIdUxvGquykAdA3xJsd36gK9lycvLk1mzZtUdHzNmjJx22mkyY8YM79d2zR23J+Xn50uf Pn08MH2i8Zd/fAmxmjKgDCgDykDHMqBCqmP51dyVAdlss82Ev9Cj4WXC3rol/qqOv+ajVVVV ybvvvuulW91x74QW/JszZ45stNFGLUipSZQBZUAZUAbWhAEVUmvCnp6rDLSAgZ133rlOSDH5 /fffL1999ZX3K76tt95aNthgA+Ev7+xeUqs7vrpLclPOsrIynZFaHVF6XBlQBpSBdmBAX1rc DiRqFp3GAIU/f2maC3QDCoAeQC+gDzDeGAMnuYxrmDbZZBOZOHGi9OjB4oqwnNzmoLy8XDbe eGMJh8MNCr264w0SJwTGjx8vb731ljzwwAMJR5InqC8tTp620JIoA8rAmjGgQmrN+NOzO5eB lBRSpOiee+7xFn9ffPHFHc7Y2LFj5dFHH/V2PO/wi7XxAiqk2kicnqYMKANJx4A+2ku6JtEC pSMD//d//ydrr712h1dt+fLlQrHG18aoKQPKgDKgDHQ8Azoj1fEc6xXaj4FWz0hxQXfUjUnM xN26MOLq/G7A78cH09Mfi+fBc5oM45iLR3Yx4+fh+xnn58/zrJ9u8LjnxzX4YNIea8zlIz+m 9f4a+P3zGO8dj6exfjYBj1nDYc9snH0kWh8W7FPlp3EEf/GA76+Pp4/H+Of7EcZfyAkBQTfo D8mtt9wiMqzXS5LlVElWeJVkh1bBrZGwUy2hUA1OjiCbWuQZhRvzXPoJFwTTDcfDXnwoAgYi YuJuzKkVE0M4DEQjyBfhmojEsiOyamFEbp+J9AFCEFBTBpQBZaAtDKiQagtrqXLOmDFZMgJr iroBOUAYCAEOkB0Je24sJ1uyarFAx8Hao2yuP/JhTHad38bR5bnBcGN+gyuFpOH5jHMCcQw3 dm4wjtdqKp1BjSReRoN8DdJG3cLuhQWekKF4ikLYqCkDTTNgqnGscRhZVX/MWYW+W4mFbZXo c1UiId/POBdxDhAKV6LjIV4qxHFXSLRypdw8oRx5aCdsugH0iDKQFgy0t5AK5uf7j8QtiLZ4 jO+OKvfdZdWOdO8XkrVqcDuKYMgsDElBrSOroo6E80OSB9eJhCTSzZGcmO+vzYdbiyHaRR7Z mJ2IhjD++67QjQHhkLghDNJxf9iB30V8CPEx+OGGEGcCfh53Ecd4pvGOx8+z8Z4Q4HmuLwAc +ikO4nF07cBPPwUB09b548IhMYyvzF5aX0BYv3XrRYs9Lyg0vGs0IUjAImnPdOOsSBa6Qxgz JJ6L5vfDiKvzhwJ+P57pGx7382Ccf6yRsNe1QDyan+l47YZ+xvn5BmdsmJ+XFuXkhyN4rOGs Drq7N8vDOR/8NeHnOXaWyPrZD3iONSTxzMYxPa0+DMmAWav6GSp/Covhxmaz6tP559TPpnGG zJ99C7oX/PnPImuv9ZjkZq2SHMxA5WTV4iNdKzlhF6SBuBALFBf1jfRx+3kwJv4ZcfADBE9Y Q2BTZDs5qAzEvPH93hcDxNmw4/1ggVXuOOM0nyfAnBW4LndHtUBYliMOW9mHyjzXuPQvxf1n qTjRMqmSpXLLFxRzasqAMpDkDNTfWdta0L/u/hpuFvu39XQ9ryMZMP6jEO/RR+AxiHEaPipp cLyJc/w0/qOWBukD+TLePoZx449lgnH0G8TbNDYfk5BHMD4Uf4yD5zPeVFMlnsgsqw7LslVZ cHNleXU3KY90l5rangg/XL6i3BNKVjRZgdCRLGverWcg3i5H4kwICYoKT2RUwMWMj9QA7Lsd OZvjyEljcvF7zzzIrTxItTzJcvPRN7G7qZPnu/QDxuSLcbpDnXZH/+0OpQvXrQ8L4oTHDX5J 6uBnmQaAa0yhp2iRSRutCnksRFkW4roLkafvdxEnCDtwjflVfiybL+On8lGlmjKgDHQBA/w2 135mF1owR8ep/wrrhePfY+1XVx73/Pi66qWFy3BTfsyX48aBPOHa8+jHHc2LC7reQB0/5okG psFN2aGA8K5DIcE4ukA83vq985kO8fQbDOaeGwjzRl93LOSnoSAIxjENz7VpbZjprEBwwv5x u+6DaXisgbiIiwgvDn66RFYM6VxeA+tGYhAatVGpqYpK6cyojPfqhkunlWFm0ZulSNz+gALP m4EryM1PqwprZTqMASOPfGgf63XURRy5eCds0ZHdU8KxHnj81wO3LLhOT9x9euF+1AfojXtS b3ye4QIOt/GIx4nTDcdHIn4k4uvNm6xjEJGMX7+fkat2X4w85iGvXxH3K/Kfh2vNw2T7z7g3 zJKbPllcn4H6lAFloD0ZCH482zNfzUsZ6AgGmhJSSb2PVEcQkep5JsGMVPJTeOaYAukdGSAm awAed8IlZACEmO86MhCVGALxVARF1fyXYmOwXsv5GWkBmeXBMT9KtHqa3PglZ7jUlAFloI0M qJBqI3F6WpcwoEKqS2hv/4uqkGpXTkOY+RqINWZDMIMFhCmu/r+9M4GTojjbeC33JSiKxgtX ARGPeJAvKoosUWPUJB6NhzGEAAAgAElEQVSIRqJR4vF9ajxi1IgghssbjYqgUQJB450YFa9I 5BSNiigYj0QFj3gQDIgCcsh8/2eYwnZ2dp1dd5ed2ef9/f5b1dXV1dVPdVe9Xd3bszXxbXC8 tiO+HfGNKtxjKrWIda/Aq8xuv8JrpK+E1ctetINVoWJeYQW+ooAdqa/I4YV6roAdqXreQPlW z45UvkrVUL4L990oNG2KU/VFJ15qx7EKnZmh6obj1K1CJyuV+oC9vwCzeYVgNv/b80K4fMr8 GqqRi7ECRaOAHamiacoGcSB2pIqkme1I1aOGPL/sW6ElDtWakh35bAnOVdgZJ2s3nK12OWq5 AOfraXgqlDSaGd5Nzcq8a5Yjq5OsQMNQwI5Uw2jnYjlKO1JF0pJ2pOp9Q5aEQT2YwWq2O//k szuOFWFJd2q9aVbN+W/BFLNWJZN5qX1S+OT9p/jYqf7r0mYFGowCdqQaTFMXxYHakSqKZmTY XfvdqvX5+YMiUbKOD+PCfbfju709aMAe7HkfYPaKeaxoqRTfviqZzqPASfwz9F/DsBkvxVUO rUCxKmBHqlhbtjiPy45UkbSrHakiacgz92wbNmq1N4/6DuBR4AE8Ftw1esnpI0yFt5nR+guz Vg+EaThYU6bo+2A2K1BUCtiRKqrmLPqDsSNVJE1sR6pIGjL7MAb07MD3sr7HV90OxKk6BKdq 80SW/5I2ke9b3YVT9YSdqoQyjha0AnakCrr5Glzl7UgVSZPbkSqShqz8MErCxb2/y2zU4WQ7 DKeq25fZUwt5BHgvjwBvC8OmPv1lumNWoPAUsCNVeG3WkGtsR6pIWt+OVJE0ZFUOY8C+24fG Tfj11ZJjeQy405ebpl7jBxl/H9Z8PsHfrvpSFccKRwE7UrXfVnPYxeVwB0yBbUF3ZvpNMZl+ 7kQ/VdEBfgn7Qi9ImrbVT9ocB7E8ProXhoMs/kCxfm5GNgJmwwNayDLtq1B/R8WOVFZjFuqi HalCbbkaqvdFPb/ND1P/lFmp4xOP//R7gX8Mq1PXhEunvFxDe3IxVqDWFdDAZKtbBfhB0zCw gl3eSbocqeS/GPOL9eFQkDOVtCtZ0DpxI4xLLA8hLvsHyFlOUqhOlI7HZgWsQDEocOn0OTzS +3V4bcrWzEb9iJfVddOnn7npH5qUzA0Xlz0WBvc6sBgO1cdQ/ArYkar7NpYDdBp0ybFr3YW9 AnqnINr+RPSjvE/EBIdWwApYgaJQQD+uPnzKxDBsyuFh5Sr1iTfwQvpSZqkO4qsKf8WhmhMG lp0QysrkZNmsQL1UwI5U3TcLv9AeroYbKti1Zp76JNYdSfw+kDNVVdOXiX+ShT6qZ7MCVsAK 1C8FLp/xVhg6+aywatXWzFANoHLv41Dtwg82jw89ucG8eL9+pNX3MSs5+x/jqrNZfxrEdkiG NXru1/eTskYPth4VNpK6dIYjctTpLtJ6w0agd58OAz3yq46pjFOz2Kc6BdWTbVLUoyL0Dpmt sBRQm1XUnkovRLuYSvPdpLSdwV8dx/fWLq77q8dYmpXeFfRe47cgaeoXPoEWEMvbjrjeIRK6 qVK5cXkucZm+KJ5Lzx+m1xbKn8tnLGKG6vLw4ZLSkPriBKr9TxyqLvwY8x/D4LKXwuDeetWh vpgG5+gkqb+OaAbN1D8NYvsojO2mNvxGpoa21b0C6vDOBr3bNAWSNo+FWfAjeBuUdxpUx+az 0feqs2EBbJMcMDQg25EqgEbLqmJst2RbZmUp+MXFHMENsBtkzyq/RNrrIMdpDETT8v2gfwyJ 9hYRvQ8p6wkToZ0Wskz/DafXAwrffjdLek0IfXkBvWuvn4VGJYN53XNn0ibyWYUn8UHPC8Om zV5PB6rBNw7AGpAVj2GMq2rJfFq21b0CsX/RntXnxOUYV6h2iulEq2Z2pKqmV03mfpjCdFd6 UY5CNQPVB+bB3aAGtn2pQDzhFeoiELqztxWWAmqz2H7JNi2so6i8troJag26cdIj/WyL13p0 pJqSQTdRx2RnzHO5+PoKvUcVpo4LfXfCoepwWtqhKuEGMdVoFrNT48PqZQPq+LMJ0TmKDpMc KBFnORTGdTGvmk9xW90pEK+F2Leor1E89jsxVLtoXbS4XVz+2tCO1NdKVKsZzqH0XHdU95B+ KWh6/8dQXdMF3T7HxotIq/LJkqOc9Z0UHShdEKt1TPxbvTur9d0q+e1f55/aTG0XO7T8tiy8 XGdR5RlwB7yfVX09yh8MG8PH0Bv0yO5vUB07hI12TWyoWa34qDGRXIDRe/8hXa4L55T9IbQN g/BLfsEy/+XXqk8YVDY0LPj0+rB2Fqu2D059jIjOk/pZodlH9z+IUACm/mdDiP2PqhydqSqP jXakJN/6szfY9fWQPSv1IWnPwNagx3zVtR3YUJ1ztrUjYUl2YgEt60TXSR8dKT0CELqL17Hp ExOaBWgFLUB3+TrX1fHZ6k4BtY+cJbWNBnR9O20p6NzTTUJst+hIKX+VOzG2qe+mR23jQDNS /bIq+y+WXwTdMCnPkXAvSJPqWF82ks7RdNNUHI5UPKLfTpHDcl4Y1INZvGbX8v7Uj5ilujps 1vYUHKpf8F+Ak2LWWgijoxSdKPUrQn1MSSpVjKdvLai4novM3HA3pxrqg2Kbqla67rRcpYa0 IyXpate+nSi+LBGP0YFERLYdkJ2QWU6WF7OcFSOJ8EHiyRMksaqgozrBRXSiNFALvUumwVrv kejuUKY8uouNaXakpErdWWwjtYFYDnKkFKqt1Gax/aIzFduXVUVlQzgavQ9VluOo4uO9P7Du MDgqR558k/qT8dV8Mxd0vuEz36T+P+bx3kH0CNfR23XFqXqC96fu4Svp54YRT/+7Fo5Pfar6 kaQjpf5Fg7KtsBTQTbbaUxb7nTi2KMzb7EjlLZUz1gMFsk92Db5Cg7QGZQ3Q0YmK6erkdLeo 9HjRELXVgQJqL7WD7vrURnKeks6U2kzpsR3jjFRsZ1YVjWkW7kIYBe9kHZXegxwOB4E0mQm2 fBUYOvnxcGr3XZiR+iWbDOYqPzo0bn4Is1O/4YHqdbXw48jRmVKfor5FTpQGZVthKRDbTP2N +p5IlY/CjlSVJfMG9UCBeOJHZ0kdms7leD7HdA3acqSUHu8iidrqSIHYMWnWSQ5T0pnS46c4 KxWdqehI1VH16nw3E9jj/8IB8FBi75o5eRb03313gc7v6pre+2iftbFmAeWgFa+tfTfqyjBw vztDo0Z63NeHK/7qsF/qxLBP2WlhxJQZNXTw2U6UHCn1MS1rqHwXU3cKqM3U52i8iH1VDKtU izjwVGkjZ7YC61GBpBOlmY44xa5QFh/zqXOLTpQcLTtSUqduLXZK6qiSzpQG9Tg7JSdK7Shi h/ZNHAmKqbem4zoT5DRl2x0k3Ax3Zq+o4vLMHPlPJm1sjvTiSxox7V0O6ihmo37AFY9jyucS GqWm8f2pCWHZygvC1TMX1MBBJ50p9TGekaoBUddDEZqRUr8U+yeNEdV6alGtjdbDAXuXNauA Lv5OoDvV90ADXtK0XgNcXVkbdqTZI53Qcnp0p/AZ5LLoECmfbgTiHaE6s9ipKS2ifHEbn++I UYcWnV6dX2rb6DAplDOlcyyGSoudWnTASLJZgWoqcGbn5qHdVhdy9fNItYRBM7WYub6L+X2/ MbzOr/Oxqqb+Q/2J+hb1N+qn9A8tG2SY5pfNUaIALPPP3ftR1U8zaIZcY5D6o3hTl/cNXV0P LHtTyXGwA9SkbUlh10OfRKES6dTEsqIngC6g7eEM6AKTYSSo85bpZc9+oGXV9a8g04UzNh37 8s9oojOhsn2dz/pdv9wk/V9412aWK9qX/uNsCHSH5+GPoP/skVWn7mu3DEEvqg8FnTRvwVag NtHjhEtBJ5FM4cZQkTOjPN/E5LwdDHNB7XY49IA9Msuq4+8hl+mcjR1adKaiQ6UOrhnEdIVC jlTcjqitjhRIsR+ha0nXnYjOkpwodVjRgYrpyhO3I2qzAt9QgUE9OoWS5tfTAxySLimVmsv/ 150dhk6dXMWS1YfEvkazGXKi1FfLkdIj1SfsSKFCAVjGkTqQqi6GT0GTCvF1g9gnqR/Ky3Ri 1KXJGekAGkhrwnQCHwfHQ2fYFKINJqLlx2IC4cOgE1/OySQYC0PgNbgAeoGcioHwJtwOx4Cc pW5wJwyCaLOJ/Bsq2pca4mUYDtEp+ZC49l/Zvu5jfVsYBtvALVAKauzq1J3Nwv5wOvwfqBw5 d6r/RqC6iNNAVtuOVEf2IR00mOok7g7/hN+DdB8BlVl0jBRGZ0mhHKnkstbHvDrX6/p8Z5cN 2lIcfWQNcfFFAnVYyWWtV36FNitQswoM7q0b12tgu3TBqdSfQmrN+WH4tHk5dzSo7BJ6qLHh yilxvFL/0QR0sxZno9oQbwdypB6xI4UKBWAZR0qOtRwpfYpF47McKc1KaVzSjZ36orysNgcW /QfFSSDH5Ua4GnaGi6AfDIaF8EPYDe6B80AH0BNOhhMg2vZEjgY5JdG2IHI+fAv2BzlO0SYQ uR3+GhMyYR9CbbNXZrkX4Z+hA8hRehY0QyUbBXL+TgHVUxei4tlW0b6k7/uwefYGLN8NufZ1 KumLYCf4N8imwR3wH6hO3XXxz4TvgxyNx2E8bAmHw44wGX4An4McKbXFr0DtcTFImx0y8WcI pWMZHAy/hu1A9TwH1K7ngsrqDT1gBqg9lfYXUNlD4FiYBXfBhaATWueG2i5ph7KgdtH5dD8o r+qpY7oatgIdg8r9L5wOOm7Ncn0bJsD7IP20nc7Pl8BWewqkMkUrFNFRkvOkeAwVj+tiXpJs VqCGFUg/7tvyXL47dRH3VW0ofSU/kDyaIXREGDlF/dZaG9CzQ2ja5D0WPgyrUgeFy6a8Rlz9 ufqUZiBHStvrZl6O1EbwoB0pVCgAyzhSP6aqGms/gU9BY0+1HKlGbFgbpgH353AQ/AzOhu1B J50GNpmWL4Ur4ED4PhwCMnWwGuySthkLKi9p77OgAfGaZGIm3olQ+34RHoP/AVlnUFq0N4m0 h01A22Sv60KaTNtp/XSQA3QGRKtoX5uTQY7IfTAXbgJdcLKK9qWLtTtEJ0qa7Qbab3XrLq1f h8XwE3gQRsF78HfQ4CXnQzpEO4qIGA1jQfVtBTr5jgC1m+p6FVwN3wGZ2lq2Nah95SAdC9+F viBTXpU1AFbC6SBHZwaMh4mQtG1YuBvkBOk8UVueCXIE74BzoSssgBvhc/gWnAN/Bu3nYjgR ToanQA7XMlOrGqhTSrKCZbWN2lyzUbo2vsgQHSiFtppXQNdjN2iRo2iNA01ypNdm0oaJwpPx RHItRG94Y0UYPvWy8PmqrvR66nOa8B9+54TWJW/ygvrAcME+6m9JbdKfv82gI/Pc08PAnuq/ oqnfi0g70TiudFgwCqjNYvvF9lRYZauti2cLarIpdIDpsDcsgY0haX9gYWom4XJCzTpokJ+Z gaDath1bPg03g5yHv8GOUAqqSzQ5LOq8NdNRCvJOo71LRHcdsm1BF9ZgkKM4DDQw3AqV7Uvb /wXk+Q4CORZyCEsh1750Z/4myOQc3AOPwj/gF1Cdundmu/kg6wtyImTqHFR2CagDeR+iqT2e zyCHSm0zA1qAyvgYWsFpoDaWNm/AXhBNdf9TZkEaSLekSV9pPx8WwqfwH1gMSTuOhUnwUCbx TMJSUPrT8ATILgEdg+ooHeVE3QE6vo9gDMwEDd7jQO1nq10FrqL4z+A3md2ovWUKc8XTK/P4 04886l+uS+Q9n/iuieVZxK/NLB9GqG10Xqjt/wqy5vBL6AW67i6DeBNTUXnaZiwkbTQLOrf2 g1OTK4ifADrntoczoAtMhpGg+sh+DkfAMrgTHgY5m5XVr7Ly2DT9esAIQt1wvAMqb3+YDzo2 Ha/sh6Dr+GAt1IKp/5fmuv47wCMgjU9JxA8nXnd25VPvs7MTwkU9R4bGjS/HmTqYWarhoUWz c8PFZXw+IZz4ZWVKNgmNmjwZBu13JI8B1W4y9SmRRsSFrbAUiO0W21Fhtay2HKknqc0EmAYa GP8AwyHb/pVImEf8gsRyjN5FZGfQoL0ZvAyys+Fv6VjuP3LmUplVcgAOBXUY6qiSDl1LltXB aFDXuk0gWmsicg5k2p+EVpk6vu1AHfOtUNG+bmJde4j1kBZ/B+2/sn2xOv29mcsIh8FvlYBV t+7vsW3sqBYR1zFuBfvCKBgAUyFp0xMLs4nrOGTz4WNFsOXwHbgF2oE6Jx1jNC1HW0pEbVgd K2WjVxMbPk9caL/PQhyMPiCu/aiuSlObrga120p4ObOseLNMnMBWiwoMpWy1hdohafGaSKbl E9+RTHI45Pyob0jaCSyon/ksk/hhJuxFqGtxIMh5uB2OgZlwFegcvhC6w2TYCdQnVFSern31 SYMg2tuZSBmhbgQeyywr0PG3gQdhEqgeQ0BOxQWgulySQfUbBZvBzVBR/ZqzrqLyWJXe3wOE F8HTsAfo+lB/sjWMBfUJqmtt2wvs4IDMTqSxrj3t+weJONH1YJdOn8Ne9fHOMhwptcl+OFXS 6KtWohvtRhPDhfv1D5dPk+7qU5I0+uoGXioABdRmyTbMjqfyPYbaanwNquoY1FH8Ao6HwyDb Nkgk7EL8o8RyjF5B5HS4BtTJKC5ehIpM+++dWClB5oMcgLehFKKVEvknqKN/B7aBaKVEXsks lBFumIkrmAcqr7J97cD6bhBtPhE5Q8uhsn39nPU6xv+Ba0H1l1W37nIgpG9b0ECjQUgDx0lw I3wLpHPSNkksdCWuzjjbepLwazgUNofrINaV6DoHR/FvYq+yscqPpjt67fsfsFVMJNwSlsJb mTQNYKqPQlmMxzoq3dSMBu3RcgxopuE50LkrbX8KfUCaT84szybUNaf0aBrwNUORNPUbByYT iJeCzs35kLQSFjYGOVcTM8jZlulauhp+D1NBDkZ/aAz/B8fANNC1pmu8DCorrxPrdYxxPwp1 3LLOoIE2uU7HfhAsBvWHOv6RoOuvEegYte/xMB1uhaOhsvpVVh6bph216wl13apdTgZd99JH bXU/HAzRmhMZC/8BadQFZKqv+CMMAtkQeA3UB6vdoj1K5HB4HuaBtpOprCthW1A/rvDuRFz7 zTZdy4/Df+HPsCvI1A9I209A+y8D2bfhThgAb8B9oG10LG/Dr6BiGz5lShg6uRdnaRmZFuTM WFLSNDRtdFu4YN9Tc653YoNVQBdxbVhfCr0RVoEuLl1Yuniz7UgSmkAbUKc6A2Qd4bB0bG2n M434S6CLR3EhJ6YiW86K2+CHmQzq1LuD6vIQ9IDtoRXIoZgJsr/AiSBddPEfB3Gdjuk6kG0C WvcnqGxfclD+Bu1AneIvQJ2DnKmK9qV9q5PVxfoBqI5COlW37ivZ9koYD2/BD0B1mQJ7wgug jitpGsRku4E6pOlayLIdWFa7vAmq3zFQAjVhqs8RmYLUce4P24B0VDtsBko/EJQu+zFMAg1c trpVQA6JzmsNaHJYfgcyDZqxffYmfiIcBQPhVmgGMp2j6i+SputW51jSHmHhlzA5mUhcA+xq uA/mwk2wEcg6gQbdaDpfdX2rn/kM3oVobxDZHiorrzPrVeZ0eBbOgGhK/xlof4+BjkGmbbLr oD5xExgMt0C0nkRUdmX1q6w8ldMLHgD1QdL9dLga1PfJuVoAm0K03kQWwv6Z8PbMCl2HQzNp cn52Bzlg6rt1vatc9Q+yXWAA9Aft6zpoBRvAHvAeXAOvwK8T8UuIZ5v29Rqo7H/BWJApXe1b CsNBfbCOsTWoj1a/0A903micUB1Ux6tA9ajclq94lZfPN4JUhRlbNL06nLfvBRWu94oGp4AG 7dqweyl0P3gLdNFuAXdBtqkT+yfoQpFdsTZIv2czKhOvTrCSjXRBXw8vwVNwMWh/80AXwSxQ h7pLZpkgnX8x4bugTu8B0MAsGwnKq/LehkUgx6ayfU1hvbafDdJCHcwIkKluufa1M+kbwjOw NMGviFe37mya/kV57fMvMA6kz40wETYAHXPSVA+1zXOgTmgZZJvauRRmwcugzn93OAy+qXWn gJszhageqqc6Vp0r0vx+0KAnfbVe55na9Uqw1b0CGnBLM7vVeXVsJp4dXEKC2k3nzgxQPyHT wDtekWradmzXBnR+Xwi7QuxzSol/AtF0ritvKSTTWUwP9q0JKytvW9bLAdSxjIehcDLItN2H cCaof/kbbAWlsASi/ZtICrSv90HXupyOm2BPGAulUFH9tK6i8lgVmsIa6AOPg+y78CSsBun+ KETTfgbCHDgblFcOiuw5UJquPeXrB6/Af0DHoWs12iAic0HngHToAtFWEdHN4XKYn4jLwUqa HNm94degtvoNPAAqax+4DBbBfaB+51CQfQrnwrOg45wCf4aHQRon68JiDmvRrD+P9ppCSY61 3CZm0ls1PTf8qscw8uTOl3NjJxarAk1q6cB0sXUDXRC62D4CmQa7HdKxtX/uIZgA7UAnejSl i6RpkO6ZTEjEdaFvmlhWVOXeDrp43gFdvNFuIDIeOsBbEE0D9MHQEXRR6mKNpny7g9Z9Dgsg WmX7Op5MclRUv3mwBmQV7UsdWWUXZ3Xqnt4hf6ZAL2gP24GO6b+Qbc0zCZsTLgO1p+wFSHZG 0qcrdIK3QR30aNCxqeNLmjrYaFvFCGGrRPyERPxB4sk2PY1ldfRfQKwP0fTjEZUt5/OfoPWy X64N1v3dZl1sbUerdrTVnALDKWocfAAz4Cp4BbJNg3G0+UQ0ME6KCYRbQhz4df6tgP+F1bAb VGTap87rVCaD+p2/w8agc3gTiNaayBugPkHrk6bz8U2orLyzWa9rVPt6EnQt9YNbYQuIdVAZ h8IPQXVI7qsly6tAjoJsJ9DNwvOwO+i6lBbJbVhMXy+q32ZZ67LLi/2MrlGV1wiOhtehF3QG XS/RniYijWXvwUKQnjLdKEWTZoPhSFgMLSBpyX78M1aoXlW1UjaYB+pnZdqnnJbvw2uwBKK9 RWRTeAV07sXj1nnzD4imY2saFyoIS3CUTqlgXfnk1s2PDb/ap0O46e9XhaVRuvLZnFL8CjSp xUNcSdm6W/g6W0oGURumi0odRy77lESRy97JlZhJq2hdbeyrompUt+6xPHXSuRyouD6G6pjy MXXs0ZKdXEyrqbCiOque+da1puricr6qgBzYH4AclmNgAmwD2daWhHgTsgvxO7MyfMzy6Zk0 OSwa1P8E0TnJrCoX6AZNzoIGVNl8WAYahHXNJutSyrLyKX0DkMMQz61tiWsArqy8Mta/BHJS ZBr0VX476A5Pgkx1ng86pmaQdARLWZYjoxFYTs2DcD5oliVaZfWTk1VRedr+KZATp3L3h/vh ErgC9oDTIGlqt2jSozHk6jsvIn0j0A3VEngIkhYdmWRaVeNyljYF1UHnlRwgnVOTYXNQO8f9 dCX+B5Apb/VtwHfb84HOsSFV0iyUpGgvwkBY0oj9Z5ZTa1qwlxY8+mtO67YMjUs2DP12Oy7c 8rx0tlmBOlfgSPb4nTrfq3doBaxAbSjwOIVq5kXWBj4CDc7XgmYTZCtAA7FMA6BuoL6tBWwf 0MxJ0q5n4cxkQiJ+FfFRieUy4h+AnBkNwEPhzyA7D54GDcByAP4FB4DsWdB62dGgeusGswwq Ku9G1k0AmY5RZf8E5Cz9G6IO/0NcNz3SQw6anLrtQbNe2v5mkI2DS0HpkTjTU1H9KiuPYtKO yN8JVYdskwN2RCLxx8TVNmqLErgAonaXEVfdoj1B5KTMgurw38SynN5umXUKXoe9YG+QcyST cyeHSJaMa1n6y4GSyVGV8yQ7Ge5Ox9bOivfNxLcm/A9Id+1jLkTT+ZGs93yW94wrqxnq/NG+ 5HxvBp1A52xvOAp4s8pWCAqorTJtprZTG6ot1aZqW7Wx2jpvU4exvixeqOtr/96vFbACNaeA nJ57QQOgOqPfwULItp4kaMDTIHg5zAHZOfAOzNZCNWwK20wCbS9HSh3h4SBT3faHd2FDGAPK KzsRNIN0OrSHPqBZoilQUXkjWfcn0LF2hqnwEKyEAaD9jQA5FXJKPsug+KxM/EPCMpDJCegK 2jbaC0S6w4mQq37zSK+oPFalZ/1+RHgz6HheBfX3nWAJDIKkSTe1H7MvacfvkOTKRHwU8ZtA zo1mgCbAQJAe39Ruo4DvwwJQ/e4A6bgUTgDZcFA+OeRbwFCQ7jYrsN4UKFlve/aOrYAVKDYF NuKASuEVWAHZprQtQXd8n4AGyJq2DShwU5CjER//xH10JPIpLIoJmbAxYRd4A+R0JO3ryvuc zBr4kyYnTuW9A8uTK4irvA7wVlZ6ZYtfV7+vK685hetRpRyo+aC78Vym8WBbUL2zdUjmb8mC 9ql8MumdrUF6xTf8o/NEM37vZ5XTmuVOIA3lpNaVqV3ljErPVqCZxrYg53xjuJfZGAJbfVcg 8z8Dfannx7AYdG3oXFoG6qd0/mf3HyTlNjtSuXVxqhWwAjWvQHSkcs1U1fzeXKIVqFkF7EjV rJ7rrbSadqR0YtisgBWwAnWhgB7L6I7PZgWsgBUoGgXsSBVNU/pArEC9V2AYNbQjVe+byRW0 AtVX4LPPPgtffKHX53iJjlDLxW52pIq9hX18VsAKWAEr0OAUePfdd9PfD23fvn3YeOONQ+vW rUO3bt3CQw/p/yJqzrbaaqswd+7cdIFnnXVW2HHHHcMHH3wQHnzwwdCpU6dwzz331NzOXJIV sAJWwApYAStQsApo4kEvwOsfBvSv8nrhfXfoDUdBvfrP/3feeUdvvqdWrFiRrhezQ6lhw4al cKxSq1atqrG6vv322+v20aZNm9Trr7+eLrt///6p4cOH19h+arIg6ZJpM7Wd2lBtqTZV26qN qzTJVKXMFG6zAlbAClgBK2AFCkyBRo0ahX322WddrV977bXw05/+NNxwww2hrKwsnf7oo4+m 4x07dgzHHXdcWK+kw1sAAAuPSURBVLhw7f+FXHPNNWH06NGhb9++YcsttwzHHHNM+Pxz/cNq CJqF0uyX8i9btiwdjhw5MkycODGMHTs23H777el8/mMFrIAVsAJWwAo0bAUKckbqlltuSY0b Ny6Fc5PaaaedUiNGjEhP7syaNSulGaTevXunHnnkkdSaNWvS63n0l/roo49SOFmpQYMGpfOe c845qXbt2qXuu+++1NSpU1OlpaWpCRMmpNfhWKXmzJmT0gxYixYtUs8991xqwYIFqSOOOCI1 ZMiQ1KJFi2pyMqlGyuI0rtEZKX0Tw2YFrIAVsAJWwAoUoQJPPPFE0GzU8uXLw5IlS8KLL74Y cJrSR6pZpXvvvTf9DpVmk8aMGRN69uwZVq5cGTp37hyeeeaZdYocffTRoU+fPunlww8/PGhG K2lbb711+p0snKywySabhA022CB06NAhbLihPrNV3GZHqrjb10dnBayAFbACDViB2267LTRr ptd++JdZnKXddtstTJ8+Pe3oyOnRi+iyli1bhueffz6ccsop4ZNPPglbbLFF2hFKr+SPlqPp xXWVZVurgN+R8plgBayAFbACVqABKNCqVasg5+mll14qd7Ryrq644orw8MMPp//r7uyzz07P MMWMmtWy5VbAyuTWxalWwApYAStgBQpegaVLl6Znj3hvKe0oyWE65JBDyh2XHtXtuuuu6U8W rF69Otx99936N8Ry+ZxQXgE7UuU1cYoVsAJWwApYgaJQQN+R0qM4fe9J/0E3fvz49PtP2Qen /8ibP39+6N69e9h5553T70rNnj07PPDAA9lZvZylQEnWshetgBWwAlbACliB8gpo4kHvFRf1 jxa/+eabYZtttglNmjRJv5yu96v4b7zyahRwSk3/1p5fNi/gk8FVtwJWwApYAStQkwroa+TR 2rZtG6MOK1HAj/YqEcerrIAVsAJWwApYAStQmQJ2pCpTx+usgBWwAlbAClgBK1CJAnakKhHH q6yAFbACVsAKWAErUJkCdqQqU8frrIAVsAJWwAoUkQL6TTy9QM7Pw6T/m0+/ncdPwKQ/wqnD 3GuvvdLr9KFOvSOlD3Ged955gR89Tn8dvWvXrkHfmEraQQcdFI499thkkuNWwApYAStgBayA FfiKApp40CfCN4DNQG9l7w694Siokd+Bq+1C9Bt6AwYMWLcb/RZely5dUtdee206bc8990zx NfR16/lJmRSOV+qxxx5Lp/GzMammTZumJk+enF6++eabU5tvvnnq448/XrdNfY+orTJtprZT G6ot1aZqW7VxlSaZqpSZwm1WwApYAStgBaxAkSig38LTbBKOUc4j6tatW/q38zKfDAg4WuH8 888P/fv3Dy+//HJ6turWW28N+l5VQzV//qChtryP2wpYAStgBRq8Avq5GH3FXI/3ounr5/q6 +YoVK8KkSZPSH/Ps3VuTN2vtkksuSf+UjJyqfv365fxSeszbEELPSDWEVvYxWgErYAWsgBXI KHDZZZelf0dPs0x77LFH6Nix41fecZozZ054/PHHw5NPPhnmzZsXFi9eHPShzmh6x+qAAw5I //TMoYceGpMdWgErYAWsgBWwAlagQgWK5h0pZp9SCxcuTLN8+fKvvNKU/Y6UVir/GWecsS4f jlaqZcuWqVNOOSXFjyCn+D2/desKIUIL+x2pCk9zr7ACVsAKWAErYAUqVQAnKOi/8kQ+P/+y 4447Bj0ClOm/90466aRw+umnhzFjxoR27dqFwYMHV7q/Yl/pR3vF3sI+PitgBayAFbACVVBA 70YtW7YsMNMU7r///sB/9K17D+q3v/1tWLBgQRgyZEho3LhxGD16dLj++uvDCy+8UIU9FFdW O1LF1Z4+GitgBayAFbAC30iBk08+Of2NKX1rSt+MOvDAA8O5556bfk9Ks0+jRo1Kr9dOevTo EY4//vjAY770bNU32nGBblxSoPV2ta2AFbACVsAK1KUCmnjQf7o3h1bQBvSrvhvCxnAv7wcR 2Oq7AplPOfSlnh/DYlgCn8EyWAGrYQ3kZZ6RyksmZ7ICVsAKWAErYAWsQHkF7EiV18QpVsAK WAErYAWsgBXISwE7UnnJ5ExWwApYAStgBayAFSivgB2p8po4xQpYAStgBayAFbACeSlgRyov mZzJClgBK2AFrIAVsALlFbAjVV4Tp1gBK2AFrIAVsAJWIC8F7EjlJZMzWQErYAWsgBWwAlag vAJ2pMpr4hQrYAWsgBWwAlbACuSlgB2pvGRyJitgBayAFbACVsAKlFfAjlR5TZxiBayAFbAC VsAKWIG8FLAjlZdMzmQFrIAVsAJWwApYgfIK2JEqr4lTrIAVsAJWwApYASuQlwJ2pPKSyZms gBWwAlbAClgBK1BeATtS5TVxihWwAlbAClgBK2AF8lLAjlReMjmTFbACVsAKWAErYAXKK2BH qrwmTrECVsAKWAErYAWsQF4K2JHKSyZnsgJWwApYAStgBaxAeQXsSJXXxClWwApYAStgBayA FchLATtSecnkTFbAClgBK2AFrIAVKK+AHanymjjFClgBK2AFrIAVsAJ5KWBHKi+ZnMkKWAEr YAWsgBWwAuUVsCNVXhOnWAErYAWsgBXIViBFQkWsyc7s5XqvgNqsovZUet5mRypvqZzRClgB K2AFrEBageQArAHZjlThnRix3ZJtWa2jsCNVLdm8kRWwAlbACjRQBZIDbxyMv2igWhTyYavN Yvsl27TKx9Skylt4AytgBayAFbACVkCDsAZjsRpSJRihrf4rIMdJbRbbT21ZbbMjVW3pvKEV sAJWwAo0QAU0CMeZDA3EqzIcQ9gO2kJraAUtoClorPUTIESoQ1MbyVlS+3wOy2ApLIFPILab 2jC2p9q2ymZHqsqSeQMrYAWsgBVooArER0AaeONMlAbrFaDBuhk0BpnyrISYZkdKqtSdxTZS G4jlIEdKodpKbaa2izNTyh/bl2j+Zkcqf62c0wpYAStgBRquAnGQVRgHaTlTGqQ1KGuAjk5U TJcTpRkppfuxHyLUoamd1A6aeVIbyXlKOlNqM6Urj0g6Uto2b7MjlbdUzmgFrIAVsAJWID1r ER0pDcRykjSWxvE0OlEatOVIKV2zUZ6RQoQ6NLWR0IyT2inpTOkxX5yVis5UdKRYVTWLDV+1 rZzbClgBK2AFrEDDUyA5G6WZDjlHcqSikxQf88mBik5UXB/zsMpWBwpER0qObdKZio9h5ejK icp+V6pKs1E6DjtSUsFmBayAFbACViA/BbKdqfjILs5+aKDW47z4SE8OlIj5iNrqQIHYTmoX OVPRYVIYH+sp1HLy0R6LVTM7UlXTy7mtgBWwAlag4SoQB2c5RRp8o3OkdC2L+KhPYZyNUr6Y l6itDhRQm8T2im0TXyxPzkTFtDiDpW2qZHakqiSXM1sBK2AFrEADVkCDrBwiDbrR4mAdZ6SS DlScibIjFdWqu1DtEolOUnSoFMaZqJgW21TbVMnsSFVJLme2AlbACliBBq5AHGiTA28cqOU4 yZGS45R0oiSZZ6SkQt1ZbKekM6W4HCe1Vwxj28V8Va6hG7bKknkDK2AFrIAVaOAKJGeYosMU w+hESaJkvgYu2Xo7/KSDJKcpLse4QllMX7tUhb92pKoglrNaAStgBayAFUgokHSUsuMxm8fZ qMT6CeUgRYvxpNOUjMd8VQrdwFWSy5mtgBWwAlbAClSoQK4xNVdahQV4RY0rEJ2nZMG50pLr HbcCVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWw AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJW wApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAK WIH6ocD/Axbad0GX4uCuAAAAAElFTkSuQmCC --------------050403010308000002090704 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example-3.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example-3.png" iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB5wURfr9ejYDS0Yy LFnMmPUMoGDOnjkrf894xvNMp2vWS2a9M+eEOYuoqCdGJKiABEkSBJa07LJhtuv/XvfUTu84 G9kwM/t9+3tbubrqVU/3m+qaahE1ZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAG lAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZ UAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFl QBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUgSRjwEmy9mpzlYGEYSC7l+uiMfoZ SpgRaZSGmJKloVCj1KSVKAPKQKtiIL1V9VY7qww0LgPOxiWqpxqX0patLae30QFt2SHQoysD ScuAfhNL2qHThisDyoAyoAwoA8pAojCggipRRkLboQwoA8qAMqAMKANJy4AKqqQdOm24MqAM KAPKgDKgDCQKAyqoEmUktB3KgDKgDCgDyoAykLQMqKBK2qHThisDyoAyoAwoA8pAojCggipR RkLboQwoA8qAMqAMKANJy4AKqqQdOm24MqAMKAPKgDKgDCQKAyqoEmUktB3KgDKgDCgDyoAy kLQMqKBK2qHThisDyoAyoAwoA8pAojCggipRRkLboQwoA8qAMqAMKANJy4AKqqQdOm24MqAM KAPKgDKgDCQKAyqoEmUktB3KgDKgDCgDyoAykLQMqKBK2qHThisDyoAyoAwoA8pAojCggipR RkLboQwoA8qAMqAMKANJy4AKqqQdOm24MtBwBpb9ZmTjRtPwClqgZFlZcrW3BSjSQyoDykAL MqCCqgXJ10MrA3Vl4MwLjeT0jmLwjkYuvdZIOOyLjGKIo7Z9jZx2XlXR8c54I7vuH437z+NG dj/AyAHHiGz5B5EjTzXy28poerA9Q3aKHo/H7r65kQOPM/Lr0vj5g2Ub21+w2kjfbUSMaf5j N3ZftD5lQBlITQZUUKXmuGqvUoyBydNEXnhEZOMSR9bN9/3vfSTy93v9jk77UaRtG5HX3xNZ vSYqOr6fLrI9hAhtwqdGXn1b5K3nRKZ95shPX4gsWSbyxPN+evD/ilUUTiJLf/KPyeNO/xzl cJxHng7mbB7/d1NFtttaxHGc5jmgHkUZUAaUgXoyoIKqnoRpdmWguRko3GBk9ryoMMrMdGTH 7Rw5GbNMH33qt4bC6cB9RbYeLvL8q9EWUojtsK0fvuHvIvsjT5fOvijJyXHk9r+JjBkZzW99 36PcoAEinTpGBUz3bo707S3Sp5efaxVmjc76sxHOlu1/jJG5v0SF3AuvGdl2Lz/t2lui8a+8 ZWSHfYxsNszIqZhNKyr2026900CoGTn5HCMPYhattNTI5dcZ2WoPI8edZeTDidF+2Daqqwwo A8pAIjGggiqRRkPbogzEYWDKDyJdOwvETFTcMFtOtkhmll+AAmgEZqLOPEnkccxAWZvCGaqI oOrdU+QfmNGiUOFsVUmJkX32cjCDVbVelqUQ48wW1y0RS5cbzIYZWbtO5Pij/NoPx7Hy+ol8 MM4Xcudc5se/9LqRm/6JdtyH2a/7RR54TOS7qUb+97WRW+8UeeoBhD8WmTlb5OGn/DLvTRC5 +yGRbbfCY8iDRc6/QmTeApH//luk+2Yi9z8aFZR+Cf2vDCgDyoAyoAwoAynBQHYvF0t6mt7u fNA1h574+2NddLVrLrnGj992L9d8+oVr1he6pstg13w92TWLl7imfZ5rysr8POvWu+beh12z 2/6uyentmj5buebZl39fL3t01GmuYf+CYJmpP/j53/7ANceeGS37/XTX9NvGNeGwa/pujbZM iqY98JhrflngmoOPd82ET6PxV93kmnMuc015uWs6DHDN+x/5aQt/9evYUOSHf57jt4N1NLWx vylxcmonlAFloNkZ0BmqZqdcD6gM1I+B4DooW7Kiwsj7H4mccpzIhiIjc37xZ3dy2zlyzOH+ LBXL8RFgRoY/A9U+15ELxjoy6X1HZn0tsseunK2yNVZ1OeP1NtZWrZrjY+aXmCnqJvLsy36+ 2+8W+XSSyMDtjYfDTvRnkr74BrNmmSJ7om5r557hyBrMbM1fJLLPnjZWZH2hCGfNZuEY3brg ceQ+fjvvx1qxk/A4s20bP5yFWbiOHUQG9P/9TFq0NvUpA8qAMtCyDKigaln+9ejKQK0M8PEb H+cF7akXRdrnIn5rR/hIkI/eOrT3BQcf+417A4IHi87t4z7+0u/DidHJl354fHjKsf5jw2C9 9PPx3vIVIjtv74saCpu8fo78YReR9HQ/N4/5Ltow6ysfP+JYn+CYc+aJ9OweXTzOXxB+NsnI VOTv3jUaX17uC8LTTxDxHksG+jcVC98p3qy99o4+7rNcqKsMKAOJy4AKqsQdG22ZMoA1S0Z+ WRAVVJyNeuAxI7dgbdFj9/gEcTbJ/pKPMTuNcDCbg1/jPYOF3BGhQqn10Wd+fv7nQveHnsJM 0B+jcdbH+gYPFOFsV9CW/yYyBPF47AbxhhmnhZyNcmT5SpFd9hNv4TzjVyC8Zq0RzqKde7nI ukKRNvgF4lKUZzztsWdFRmG2qk8vXxDyF3zW2rUVmYH1VS6evi1ZxkXquiDdcqOuMqAMJC4D ke+bidtAbZky0JoZ4OwNbdjO/G+82Z+9dxd5E4Jki2G+4KEAGhEQJMzJWapLr43OUN10teBX ddhW4V38wg4zRSWlIqP3FrnuL8xd1fioMLY+5liwWPCrPH+W6ZpL+Ss9kX/eZ6Rgtcitf/Nn y4YMNHLng3jUuIf/CPDgMSKH7u/g8Z6Rfz/g733FPHyM9/i9/nE5e3XFn6Nt+PP/iRx+isik b0QorvrgsaCdaYvmUp8yoAwoA4nFQNWvoInVNm2NMpDQDHABM/dnShbjzujcfqFzp9//YrAh fVhZgEeDmHUaNtifqQrWsWiJ8YRQKBTlhzNWPD7XQ/XsHo0PlrN+zsytXOXPlDXn3lPcwLRk aaDRtkHqKgPKgDJQCwM1X9VqKazJykBrZiDZBFVrHqu69l0FVV2Z0nzKgDIQy0AoNkLDyoAy oAwoA8qAMqAMKAP1Y0AFVf340tzKgDKgDCgDyoAyoAz8jgEVVL+jRCOUAWVAGVAGlAFlQBmo HwMqqOrHl+ZWBhKSgTnzjLz7ob8lQWwDf5rlb74ZG7+pYb6rb9K38Y+5qXVreWVAGVAGko0B FVTJNmLaXmUgDgNPvyR4V16cBET16yMy4dX4aZsS+9xD2PxzxKbUoGWVAWVAGUgdBlRQpc5Y ak+SjIEXXjPCWZ7BOxq59pboTM8X3xgZfaQff8FfjYTDftoNfzfYENPIsWf6M05nYy8obrJ5 651GHn5a5OU3RD7/yg8/8rSRk8/hpphG7oHw4e7jtNlzjRx4HPaz2sLIiWcbWbDIyL0PG/nb rdHjL1xsZL8/GuE2C/PmGznsJOxdNcxg804j03708/FFx9wYND3d8fJdeq2RftsY2fNgI2++ 7+dh2+76j5ERI308+3L0GH5r/P88TrzyfHnzX2/w+8pX3LAvNNY76nAjz73iH4/H/OZ7I+Rj 0A5GTj/feJuC+rXrf2VAGVAGlAFlQBlIaAa4bUJD7cXXXLPF7q6ZPM01n3/lmk4DXfPtFNfM nuuaoTu55qXXXcOXAu+wj2vuf9Q/zo77umbnMa754hvXPP2S/8JgvgD516Wu6TzIfyHxxo2u 2eMg12y1h2v+fq9rlv3mGpab+D/XLF/hmv7buuapF1wz9xfXjDnKNXxB8X8ed83oI6N94QuL b/6X/1Jl1sO2rCpwzRX5rtnzYD/fbXe55sIrff9xZ7lm7EWumb/QNTf9E+3f2Y//x32uOeQE v1/vjPdfgMy2xlp15fniZx6D7R7/iWty+7tmwWKfI3J/3l/8l0Dvsp/f/yef918QzTTma4ix bEKfdNo4ZUAZUAaUAWUg1RhoqKAKh13Td2tfANmb/gOPueaXBa4580LXvACxZe3aW1xz8dXY QBRCqW1f18z42U9jHTx+wWpfyHTf3I8vL/eFy/sf+WGWa9fPNWvWuuaCv7rmz1dF6/50kmve fN81Ez51zfDd/HiKosE7umZDkWsef841514ezU/Bt9kwP0wR9NizvlDL2841bA+Nwotiq3CD LxgZtsZjUDwGjUIvXnmKKArL0tJofgq1Dye6hmJ0xEjXuK6fdswZ0X6VlbmmTR/XrAwcN3i8 2vwqqFLtU6r9UQaUAWVAGUh4BhoqqChkBu0QFQT2Jk9BRTFAgTFghI+uQ1xz+93+LM/mu0bF xSzMXlGU0V57xzX7/dH3/zDDF0S2TooglqP46LeNayZ9E63D5lmwyDUdMUNGO/tS1zz0pJ+f Auj76dH8H3/mmu329sMUO0y7CGLv8uuieWyd/37ANe3zov1gfygI58yrmre68tfc7BrCGtvf a0vX/DTLn1Wj0LTGmb6vvvPDU3/wZ+FsWn1dFVQJ/7HTBioDCcuAvssvYYdGG5aqDMzB61d6 dvfficc+/rbSyM9zRNauFxmYJzL5o2jP12/Aq1rwwuEnnhfZcbtoPN+3Z18ozHfh2Xfv8d1/ wRcl27R1qHsFXuXSu1e0Dq51OmAfvoZG8CJjke+mGvn2e5H778ALjZGfLz/usVk0/8tviZx9 msjqNUaWrcB7+Yb5L0Teb2Q0z+RpRjrh1TI87kVni1x7mZ8WRv0lJXztTdWXM/BVNPHKf4/y B42O1vvJ53h34VD//YVTfjDyJ7SDtm69kUW/imyzhR/mcS0vfoz+VwaUAWWgeRjQRenNw7Me RRmoZKADBNKKlSJr1hoIGSPnXg5hUCiSixcB8/11xRv9d+O9+b7ImKMovESmQChY0cSKKBys cJo+Q2T4EL965gsKCq/cNiJZmQBeSEzhRnvqBSOvve0fh+/bG9hf5GK8QPn6K/yF5hkZIsSM n/38vyww8jFEzenH+8feAmIqM9ORDrmoc66/UPzXpUbOvFCkU0e81LgdBNki1uWLtQv/Kt7i eNb29WQjc3/xlypVW76NyCy0FTNMUl5u5F94sfJl5/ttYd9HoE+0aVhsz3cJ5uT4Qo1CLMiT n0v/KwPKgDKgDCgDykDCMtDQR35cX7T7Aa7pjUdY249yzd9u9R9XcR3S/sf465S23tNfKD5v vp/G/J98Hn3MxQXlfNRH42M6Ps5b9KtrRh3mmvcmRPOxHNcd0W74u/9IcafRrjnoOH+huZeA f0ef7pq9D42WY/zVN7kmp7dr9jncNVv+wTV2XdY/73fNn3BMGh8h8rEk07k4/IOP/fgfZ7qm z1b+4ni2jQvMub6LNmwX1zz/as3l+ViUC+25VoqP9NgWGh9P8tGftbv+gwXxF0fDex3imjfe i4Ztvrq6+sgvYT9u2jBlIOEZqDr/nvDN1QYqA4nDAG++G5c0/CO0aImRPj1FOENkDTd+zN6I pKXx8V803qZX565dZ6Rjh9rzF6w23sxT+9za8/JYS5YZ2VAkMngA2xS/TGmpkYI1Ir16VE3n tgdz0JdePUS6dK6aFuxHdeU3FBnvseMAzJ61a1t9+WBdm+rXlyNvKoNaXhlovQw0z1Wq9fKr PU9hBjZVUKUwNUnbNRVUSTt02nBloMUZ0DVULT4E2gBlQBlQBpQBZUAZSHYGVFAl+whq+5UB ZUAZUAaUAWWgxRlQQdXiQ6ANUAaUAWVAGVAGlIFkZ0AFVbKPoLZfGVAGlAFlQBlQBlqcARVU LT4E2gBlQBlQBpQBZUAZSHYGVFAl+whq+5UBZUAZUAaUAWWgxRlQQdXiQ6ANUAaUAWVAGVAG lIFkZwAvhlBTBpQBZSB5GOCGn0uWiSwF+MoebjxaBGwoBjaIWbfeKcM7EMPsUU6WhLKzJS0n 26Tj1Tshvn6Hr+HZrJtI/z4i/YDgexWThwVtaYIzEG+Px3hxCd6NlGqe/76rql2KF1c1Rz1C KqjqQZZmVQaUgaZnYGWBv8P6XLw4ee4CqcBLmjfiBcjhpcsltLJAsvAiZycnRwqyMmQJNpZf 57qyPlxh1pWWyRq8gHmN45gNwHoxTppxJEtcyaKbHgplpWe6bTPSJDs7KzTAdc3AkjLpWVYq bTbrajb27ePgFc6CNxGqKQP1ZoBiyQqmWL+tzKbbsLrNy0BQPFk/3Xj+BrVMBVWDaNNCyoAy sCkM8KXQc+eL/DiTL1d23B9nmuKZs53wgsUmBwIonNNGFhlxZqxd506RCrPUhMwS47pLykqK l8jaTms3NODgZdWWWZyzxN2s/9LfQv1dMXg9tZoyUGcGguKJS2gYtq71s7JgPobVmp+BoHhy cXgbtn66HCcbX+8WsrCaMqAMNIABffVM3UhbscrI9J988fT9dCmaMk3C8xdL2zbZUpCRKdML C53JJWUVs4xrZoc3bpwthe0L6laz5lIGWpQBK5LoUkRZ4E2cnp+uTbN5EeXF0VVrHgYokGhW KFkBxRlp+q1Lv02zeRFVd9MZqrpzpTmVAWWgFgYWYF5p6o8i3093wl9+a4qmz5CM8jKpyMmW OXgJ8jdFG83kCtedXh5a9WPRnF5Y9aSmDCQtA1YkUUhRPFmshZ9paonPAIUTH/NTVBE0iiqa FWJ+qA7/VVDVgSTNogwoA1UZwPojmT1PPPE0eapT9uV3UvzTLJMTCkkRFn7/ULje/ayswkwu Kyn7Xla3WbymanENKQPJzoAVTFZM8V5KZACOweI+tcRnwIGhlfipipQDdkzZcIorhus1kCqo SJ2aMqAMVMtAWZmRGT/74um7qVLy1XdSCjHVJjtLCtLTZeqade5nxriTS2Xj97K0va5BqpZJ TUghBnizDT7i470Uvx/1bs4p1M1W0ZVs9NKKKQooC/v4r84kqKCqM1WaURn4PQOFG4zktrOf xd+nJ1tMwWp/vdM0rHn6dqqzYfJU4/66VNq0aytL0Mvv1qwz/6sQ9/tw+dophQu7YdMCNWWg 1TJgRRUf9XFmijMdvDmrJRcDdswopOw6KvvYr149UUFVL7o0szIQZaB7N/NY762ck7bd0pQc ebCTe+BoExo+NDnEFfdymjlbZBYwY7ZT/v10U/z9NMksKZVQ+1yZVVrifFm0oeLbijR3avnS hT8VyZDSaM/Vpwy0egZixRQFFWeoclo9M8lHAMeMAoqP+YKCqt6iKjmu/sk3QNri1sJAr6Vt sio22ye3Q9oRxpXDsrNNm0P3d0IQVznDBosMysPCivSW+ZiVlxvB/k2yYLHIQgBbFJRN/dEp /nmuycCGmJm5bZ2Fjpgf16w335mw+cEJhe5xTfnBZcuzMD+lpgwoAzUwYGelKKI4w9EmgnZw v9Y1VGAhCcxfQiW7oKnciYU/kiFKAO6ywnVVdqE6vLVby1zpa2+X5lAGkpKBzJ6lw9Oc9IM7 dnIODpfL5sXF0rV3Lyneergj220t7bYYZkJDBwkeE+KnJR1EMBskkQ91nfvLBeEFWOVdsFpk FYFNBuhfvkJczDoVz/lFwr8uddLXrjU5bdvIamxNsAj7Pv28dq1MwfKAmY4pn1HyW/YCHDm6 4LLbhh7ZGW1mlCx1ulSJr3OrNKMy0GoY4H3TCio+5uMMBwUVPs0esKYw+tFCnFqCMhC59u6F 5nH5AkFBtRHgjLwVVHUeTBVUYE1NGWg6BuZkZXTrP9zJCG2Rle5sjfVWO2Nn7wHhCsnFzt7t ysslq02OlGKNUnmH9uJCYLll5eKE8eKUigpHysPGoQtB5EBHyfr1klm8UTLxS7rizAxZh0Xh q/EhXoGdwpcXFYV+CZdXzIdoAsILSpa/hXmpY+v0DSuzR/hYzFCdVLo0dHjTcaE1KwMpwQDv m1wuw8d8dnaqLfwUVPwJ/ocqqMBCElhEUI1BU7nVBQVVEWBnqSio+AqrOgsqXUMFttSUgaZj YEhp+UqZivqncg6Zn9iqlh8qaX9Jx6LCrE7LVoY64V0p7cLQT/gLOyETxu+Iwk5FxA2bcGlG 2RpZ+u/VGyW/3s/3qx63asgRZ09xzedVYzWkDCgDNTBAYRX8pR8FFqGWXAzYceOsox3PBk02 qaBKroHX1qYcAxBG6/NXl64XPLTz55hboouOcV8rKSnCI0E1ZUAZqCcDvAnzZkzoPbWe5CVA do6ZHT+OZYNNB7/B1GlBZSB1GCj5LePj1OmN9kQZaBYGOIthYWc2eGNWSy4GOGZ2/Ox4NmiG apPUWHJxpq1VBpQBZUAZUAYalYHgDdjelBv1AFpZkzNgxy04lg06qAqqBtGmhZSB1GEgq3v4 kKye5funTo+0J8pAkzIQvPHG+vWe2qTUN0nlHLPYcQyG63xQHfw6U6UZlYHUZMBJC12NDRS4 Zl5NGVAGlAFloIEM6BqqBhKnxZSB1GBgfjZ+E7xd6fLlX6VGf7QXyoAyoAy0DAMqqFqGdz2q MpAQDGT36LMrGjJNpC83s1NTBpQBZUAZaCAD+sivgcRpMWUgFRhwJbSnEd1/KhXGUvugDCgD LcuAzlC1LP96dGWgRRkoK95wv6xfwd2B1ZQBZUAZUAY2gQEVVJtAnhZVBpKegfUdvA1Fk74f 2gFlQBlQBlqYAX3k18IDoIdXBpQBZUAZUAaUgeRnQAVV8o+h9kAZaBADmb3CJ2T1qLisQYW1 kDKgDCgDykAVBlRQVaFDA8pA62HAMaHjjDG/tp4ea0+VAWVAGWg6BlRQNR23WrMykNAMOI7s VVZR+llCN1IbpwwoA8pAkjCggipJBkqbqQw0JgOZPUq3MEbWyKq2yxqzXq1LGVAGlIHWyoAK qtY68trv1s2AkzZCHPNa6yZBe68MpCYDJ598smRmZkq7du2kbdu20rt3b7n44otl3bp1jdrh e+65RxxMdX/++eeNWm+yVqaCKllHTtutDGwCA2XL0p8tXZp2+SZUoUWVAWUggRm4/PLLZcOG DVJUVCQ//fSTvPvuu/L44483aoufeeYZ2XnnneX5559v1HqTtTIVVMk6ctpuZUAZSBYGpqOh J0YaOxHuQqBNJEwnC8ArFaUrcAvwKRBrzyHimUikre8KhPlSa6IiAhu+HuHDANYbC33NEEhp TdaxY0c54YQT5JNPPvG6vXTpUi/Mmav99ttPPvroIy9++vTpcsYZZ8gdd9whAwcOlB122EGm TcObqeLYzz//LEuWLJE777xTxo0bJ+FwuDLXgQceKE899ZTssssunuCaOHGinHfeedKnTx85 6qijpLi4uDJvKnlUUKXSaGpflAFlIBkYaI9GXlNNQ/lVfw9gs0B6JvwHAxRVQfs7Akwj7gce D4RvgJ/2E+DEIIcJaq2HAYqiF198USh0aPfdd5/07NlTvv/+ezn11FPlggsuEPzi15vN4qwT Bdf7778v/fv3l2uvvTYuUc8++6wce+yxsttuu0lOTo5MmDChMt8PP/wgDz30kNx1110yYsQI GT16tJfn7bffFgoxtkVNGVAGlIGkZyCjZ/iU7F7uS0nfkeTpgJ1RYosnAlcB3KF+CEALzlAx /ANwNj0R411wFZARCQfri0TJPfA8YgMRlzNUP8bEaXDTGeBEBEVsLtAdGASMAEYBfwSgTVrW TjrppCqzkqFQyIwZM8asXbvWa9j//vc/U1hYaFzXNVOmTPHyrl+/3kyaNMl06dLFYLbJy/fF F1+YIUOGxO3MgAEDzNdff+2lXXTRRQbCrDIfZr4MBJkXxvoqg/Vc3vEYgbVc5sorr6zM25Ie jlVkzDh2HEOOJceUY8sxrtekk756BoypKQOtiYGQOPpC5JYd8MU4/D+Be4ED4jTlOcQdDTwU STsK7stAeSRcH6cDMh8fU2AOwpNj4jSYYgxwEbqdXeLC9Ozs7Moe8vHcEUccIRBTstVWW1XG 09O9e3dJS0vz4riofePG3z8hhtCS+fPnyznnnOMtSi8oKJA1a9ZISUlJ5XH4eI/GxfH9+vXz FsgznJ6eLuXlDTmVWTqxTQVVYo+Ptk4ZaAIGnD3d8vADTVCxVll3Bv6FrGcCRwLvxhR7AWE+ susErAcOB44BGmKsIzjbxTpeB1RQkYkUNj6Gw2zT73pYUVEhJ554otx2220yfvx4KSsr8x7H 2YyYzbLeal0+Fjz99NNl7NixlXkwK+YtfOcaKVpd6qksnCIeFVQpMpDaDWWgTgz0KOyGFTU9 y1feOr1O+TVTUzFQioovArj2aSIQtPkIUPAcCiwEmPczoCG2AIX2aUhBLZOaDHAmiTNKhxxy iCd6nn766Xp1lALspZde8tZY7bTTTpVljzzySO/XflZQVSa0Ik/tUrQVkaFdVQZSnYEMyRpg xNwmku+mel+ToH/voI1c43R1nLZycTof+3EGiyt4udZDTRnYZAa6du3qzS5xsTgxdepUoTDi Ngt1sffee086dOjglQnmp6B65513BGuzgtHqVwaUAWVAGVAGGo0BzgaeGKltItyTI346gwHe gSiYugLWesCzAVgC7GAjI26wPpt0DzzxFqXPRHznOHBsQXXrzQAnIrhgORdIyEXpdVnojV/y GWz06WXlIvRVq1bVpVhK5cH4NeqidJ2hAqNqyoAyoAy0EANzcVyKoVhbjoivAIqqTVnvtDnK F8QBxYBaK2aA2ya0b88dPMRbhB5vvVUrpqdBXddvKQ2iTQspA8nIQH4oo8fVO5Yvz/gWWxPp I6RkHEJtcyIwwIkIrj/mdhfcoLUdQGXSEegCjMM0Dhy1RGeAr82B8Qcf/NKxFlgP8EsMdx7l 2sUwUOflETpDBbbUlIHWwEBWz2vGpDnp2AxSxVRrGG/tozKgDDQvAyqompdvPZoy0GIMOBLa E0sGPm+xBuiBlQFlQBlIYQZUUKXw4GrXlIGqDDh7Gcf9rGqchpQBZaA1MnDyySd7m25y805u /Mn3+nEzUCxU9+jYddddvc04ubaKayx3308AACAASURBVK169erl/RKQ+1hxs89hw4YJdkiv Qt3+++/vvSOwSqQGlAFlQBlILQZ+yszq5RZL9+VtU6tfrbo3XLOzNcBf8ak1HwOciEj6X/nx 9TRXXXVV5a/2sD+V95oZvOzYi8OLjQ32qKpMx/YK3itk7CtlvvrqK5ORkWHwwmUvz3//+1+D he4Ge1xVlkl0D8ZRf+XXfJ8bPZIykCIMdM3rasQ9S37rUdQIPdoNdcxqhHpiq+iNiFdiIvdC +JkY+O/FEBmK+LsB7jT+FyA4487dxbl/E/dz2g+wVlN9rCN4rEsihbj4OBhP/+6BtCvhfw+4 D2AfYu2/iNg2JrK69vFYtdV3GvLweP8CuKD2OeB7gHU2lZFrvhswnjXV+fArDkbBqNYMDHTs 2NGbXYJAinu04cOHC/ewiizkFggu+ctf/iJnnHGG/Pjjj97s1SOPPCKdO7defZ8elzmNVAaU gdRiYFXbpWW+uGiMfvHmPboxKorUkQuXezOdAgyOxFlnJDz89c37NgIuf3XDX1a9CUwArgFu ALoBVwB7A/8BGD8PeAY4DpgEjATi1YdooVC5GeCvfGjcuoA2EOALz65lIGILI+4/4O4IUARx vyjejbYEyoFDI/g/uBQ91mpqX031sfy9wFzgYKAnwD7fCFDIkYONwHigsY19OxUg57HW2OeD rZ+i1Y6BjVO3iRiYNm2avPjii95jP3sIvNhY+N6/0tJSmTBhgvD9fKNGjbLJcv3113ubeVJc 8XU2Bx10UGWaepQBZUAZUAaqMsBZmh+B+cDlkSSKCysQroP/PICzREuBu4B0gIZF8PKk54v+ GwpvUJgwpRdwJ8DZpBVA0J5CYL9gRMR/NFzu02SNIqUACAGcmboMsHYfPA9HAtXV5yB9mS0Q 4x6CsC0fTOJMGXSq9A1Esv1jIuGr4bJf6wG2z1p17autPs4EPRup5EC4/IHB+QA5vgegwHoV sEaR9QGwGmD8tgCtLfAIsBj4BNgZoG0DPA78FfgFmAywDPeyYpiLayjoGGY7LgQmAsHzgX24 AyAP3wCnA2zHdwAfUVqj4D0S4HhRxPLcWQLw3OBY0F4HBnk+X0DOgp9tZl9zIvFs86cA458A 2gPxjAI0XnmeWzy/2bdXgO4A7VKAM5YvARTlFOonAD8D04BdgVyA+dnGEcAo4I9Aoj/p8trH R35sqwXevWfGjBlj1q5d66XzkR/WUZnjjz/eHHvssWaHHXYwQ4cONTNnzqzSv8suu8yr47XX XqsSnwyBSN85Zhw7jiHHkmPKsc0EeH6qKQPKgDIQZSCrR8V50ETZ0Zg6+Xjj/AHgDZHiiDet ocBuAG9ONM7+cMZnb2BLYAZwGEDjDMNDni/6j/V8Hg1W8e2EEG/EQfsCAR5jKvA+wDw03vT/ 4/n8f33g8MK+GcCb976AtUvgmRgJVFdfL6Szfy8D7DPr7gTQLgY+BthuigSKGNoAYLXni/6b BK9Nt7EL4CE/1qprX2315aMCy+1E+Dk+tE+BgwA+LqTf2v/guRug4KPI4XFp5PM1YDhwPMA+ dAY4ruUAy3CcXwXeAjIBcsC6ewLbA4UAOTkQCJ4Pf0Z4GjAEOAAoBgYD5JTHovFmxfgewAXA twDbOAyYCZwO0H4Ftgb6AxuAQwG2+UuA498eWAlQ/OQBPNdeB2KtuvI85hpgDNAV4Ji/C9Du BJjGNh8BuAD53Bm4H3gPYD+6A4OAEcAoIKkEFRahezukc5d0LDSvooFi11AxkfnPP//8ynzT p083eAmz+b//+z+Tl5dnioqKKtOSwYPx4jWj0QSVqi+wqaYMpDIDGb3KRmDhA25cA0rq2U+K jM2AbgDFBG+cy4FYexIRvNn+BNwOHAzQKC7O9nwN/zcQRXnMC4F5wEcAxVMesB6wtgQeXhzb AnnAOsDaYnjaRQLV1cd45uEN+UpgW+AFgDYAoKi4HngCuBEYC+QBweMg6IkAtqEmy0NisJxt X2w866CosPXxxj0f6AGQg1lAGrAlMBHYHRgP0IYCHC8KD9afD7wBdAKOBy4BZgLs41SAgozG dlGgzAb+CVDklAG/ARRBywBaNnAMQGERtDMR+DswB3gfOAcgdy8CFEQ0HmsSsBwgjw8AbOPP AMXKCUDQTkZgAkBxxzbbc+FY+Dlz9m9gAXA1wLotX/B6Vl35U5BKcfYhsArg+FIgUqjRXgHI D88J9v9B4BvgWWAIkPQGMST8FR+Rnc0hrdm22GIL4aNBGn/td9ZZZ8l5550nDz74oPd+v+uu u67mClI8NT3F+6fdUwZaPQMhk7YXtMZnDSDiY5R5CmDZlcCTwM1ArPHmaY03/CtsIODyxrQV 0AboDvwI0C4CKJKqs15IMJHE/8E9GDgE4M29C2AtBx7OrvDGzDTOOFjjDXZuJFBdff9BemfA Hov9/RrgMdhGB2AaORkInAjwBh5sA4Je/yj8arLq2rcRhWqq71ek9wbIcVYE/HbN+A7AVQBn iGh5APOVADTWfROwAxACKAyskZ93ALabwqECoG0AyGs8W4DIgjgJeYibGYjn+UPj2JDPdIAz Ps8DtDyA8dZ+gaebDUTcPLjBOr9DmLgd2BpYAVhj38hhkY2AmwfEK/8w4oM8sO8sZ49PXq2V wTMjEiA/FIkpb1w7VVxczGeYMn78eMEvAOWUU07x+n3XXXfJihUr5IYbbvBeXfPAAw/IyJEj vbVU22+/fcpzE6+DPPnUWp6BYWgCL9YZAD/M9D8IBI3fsngxp80GLvB80X/8elEIHAYE6+PF ihcDgvXywmbDW8H/TCSeaUHYCyGi1ZKbAWdP07ANPXmTvh7gOcnzjVfSw4FYyw1E8AbHG1Os 3YGI8wDOJsyL+Bnm7Eh1xuOPCiTy/FwA8Ea+EMgDrOXBw89FGFgE9Aes5cHDm2FN9W2O9OGA tQXwUPhsBEYCHQFr8+FhG3gc9p1CzNoAeH6ygWrc6tpXW32c8eHsDYXOzcA7AK8Z44A3gMeB WQCN7mZAGgMw5uM1hDNQ5IjtZDrRB7DXGxf+TTEet2eggjHw9wXmAAuAfYB9gVcBGrni8a3x 2vWlDURciqFgnUMQ3hNgX8YDth90+wEU1UGrrnzssXujUBFAUUfbVC78WpL4/9ixY709qrhX FfecwhorufTSS2XevHnC2aj77rvPS2cXd999d09s4fGfN3uVxN3Wpic5A7yI8GbBi163iH8V XH6btMaL4ceRwA0Bv00/FJ7VAL85Beuz6XSXAfsFI+CnoLo+Jk6DKcRAdk93hXQu5k2tvjYW BXiTDkUKPg/3LGA3wN64ef58C6QD7YCPAJ6fNN7cYgUYb4SfMzGO7YS44GwDz+UlwCGRvEzn lwYeh4KAYmco0AZ4CvgvQLsc+BJgu3nz5c18NFBTfSORzs8HRVcacCNgb/r3w8/6aV0B1n08 A7BvAB6PdixAMUkugrYAgb0DEdW1j1lqq+855Pkz4DBzwCj4LgmE6Z0GHBeJGwv3RYB9mw/8 H0DjebEUGAFwXH8ArG0Dz+JI4Bi4EyN+Tj+QU2vB8+EaRD4LZAE9AdZN0Un7K0AB/QYDEbsK 7tMAvxCyTzx/jgBovwJbA0MBtqM/wPa/C/wR2BVYB/A8o50IUFTTKI6O9HzVlx+M9IUA66Wd C7DttDuB6zyf/4/5yBFtF2ARwH51BwYBTBsFsF3JsHxI28hpN/++yzHj2HEMOZYcU45tJsBr iFqSMTAM7eXgZgDdIn5eNL8CHIAWFFT8Nh0GmNfa4/A8EgkE67PpdJcB+wUj4H8GCF44YpI1 mNwMzM/GGqqGzr9TXMwDFgBfAp8CfDwUvIHy/PkE+AXg+cUbIgUOjQKDN8Kg7YnA58GIgH8n +FcEwvSeCrDuaUAZcDFg7UJ4KLB43CkA20vjhfA9YAlQBPwTsFZTfU8jE4+1EGC77ReagfCz fraB9fGGTh5oWwDLAZZbC+wLxNoCROwdiKypfbXVxwv834AJwN3A1cATwJvAH4CgHYoA+ZkL sO3bATTePFYBMwCmUwTROK4/eD7/X1BQ5SGKYvExoCZB1QvpPBa5J48cI2t58PA6Z8Uo4/sA bAfFE0X620AOQGPc1p7Pn0HbCD95fh1Ii8TfDLcUYB08Hs8v2mFA8Fx6EOF45R9FPMvz/J4P bAvQ7gSu83z+P9Y9IhLeBa4KqhSQZBhHno8qqCIndqo4wyIDGxRUvKhMBs6MdPJkuB9H/HR4 gR8bCafD5QXSXsyD9UWyeA5vPPEEFR8Z8CIXRFCseYX1X6tkgDf/rYDu1fT+GcTzmz0FBm+m TWEUETyn7Y02eIxcBAYGIwL+fvB3CoStt7b6BiEj88Qa69ssNhJh3tz5JYefw/pYde2rS30O DjQAoADIquGgHL9448IyFExdaygbm8TrkxWSsWmx4b6IYD/qYra/8doZLN8ZgQ7BiIiffSAP 7GtNVl35nig0HKhre3lu8Fg89/i5GARQbI0CeHNOAanROrrAsYqMGceOY8ix5JhybDnG8a4D iI5v9b0AxK9FY5uCgQpUegHAb2OvxTnA84g7CngE2AsoAz4BGmL8Jt4lpuBMhFfGxGmw9THA 8+rHOnSbMzdEU5iLSn+upmLOsBDxbFG8SMQ1dn38rHJ2pb5WXfvqUh9vBPPrcECO39I4+Tgr Mz1OfE1R5Ugk6mKL65Ipkqcu/WXW1dXUyS+TRG1WXfllKEioKQObxEC91NcmHUkLN4SBL1Ho feDmOIVfQNw+AL+xUVi9BPBG0RB7AoVYVxDTGlKRlkksBrD/1L3Spbh3E7bqVdT9bRPWr1Ur A8qAMpAUDOgMVeIP01/RRK4P4DfKoC1CgDeyw4AjgKMBNWUgygCElBNyTpCCNhdGIxvdR0Gl pgwoA8pAq2dABVXinwJc8MoZqtuB/8U0l4/9rgcotr6OSatPsA0yc31B0Di1X92jlGA+9Sco A5lZmXvhdyyfJWjztFnKQEIykN8WG6eG5CMsUuNjVRf/DH4axNl/tzIO+5B4ifjRENwQMjkF rkz/b7G3lUVC9ksb1fQMqKBqeo4b4wj3opKxAD7PVWwcQncDd1SJrX+As2BE0D5A4IBghPqT iwFHnD1xL/g8uVqtrVUGWpaB/CJZnp+LX2w63s7zv7vosnUOrsS8GIciTV3vyltPFntbLnSM RKnTChlQQZUYg/4zmmHFEheCW79tHWeL+HPqWGNe/vIm1oL1BdN6BgMRP389SKilGgPG2dOV 8GOp1i3tjzLQDAw8iWPsXpfjrK3ABuJF3l5aKqbqQlgK57ECO4W7qF1TBlonA6XLQluXL8v8 rnX2XnutDGwCA4X4kY/BL6fxaK/aWoyUFoTlXIip+6vNowmtigGdoWpVw62dVQaUAWVAGaiJ gevayhg8y7sYeTLwrCD2aYEtunqVKyfcW+xtYtrORqrbuhlQQdW6x197rwwoA8pAq2fgbIin 3rne0ofLIKG29AjBDBTcrEpyOFsFgYUpq7lYgH74vUXebvr8QY+aMuAxoI/8Uv9E6Isuchfg 7NTvqvbQMpDV0309o3vZLjasrjKgDPyegXy8Jim/vfy5d3u8YsnBa3Uopgxem2Pk6kIj/fBT vhVeqYiYQvwXiN/t3g3e63x+X6HGtGoGmnKG6k4wuwH4WyMzfCLq42tR+Os2a3+Bh68esDYZ Hh6fdjjAMvzZ6+PAeIDGbx6XAHsD84DbAL5/ilZdfSzzqJcj+u8BeCcBewH4olPFTkOoAhgK nA8MAT4B/gWwPda48eI9QHAvqZraV1t97VHXLQDrXQRwUfu+wAKAfWN/m8IOQqULAO6bFWtN cT7shoNwTDePPVirDvdaym/N+5X/tvC4Vs2Ddl4ZqIaBfL5gO1cuwPO8S5GF9xPug/Ajfr13 uymUF5EeZlx+O3keIuuiyMzU8wWFcgZ+cs3raVPeO3lotSRkoClPipvAh2lETrZAXUcCFEEv xNRL4XIzQAFHW+47nlj6D/zXABQRzwC8yVAA/QPYEbgS2AGg0OFULz8s1dU3EGlbAdcC1hZG PCPhrgW4s7k1iiY+X38TmACwHTcA/ABfAeQC/IXdKcBgIGjVtY9Cq7r6WJ7HewO4GvgS2B5Y BnA8+gKPAkcAbGtj21hU+DYQT1A19vnAtn8PjKantVtW9/BhONm6lv+W/lh2RbfdsAYE3Azh Iws1ZUAZiDCQjxkpJ1cuxI3pcoinrl60ka8RvjW/UN5CGN6AufIUPksXIfKW/PXe5ADT9clO gCL1Ni4DPCn/C/CmzZkh+5jhz/DzBkubCFA4TAVmA8GZGN74/w8IGgXGmGAE/Jz94CzHd8B9 gDUuGuSx49mLiLwskMByDwNpQBlAgWFtBTw8Zk31HYJ0lo9nTyFyvzgJ7OtXgfi94S8A+KHs BbBPzwM8vrWa2ldTfSz/L4DCk/YgwBm0vwPvAnsCFwEnANYOhmcWsBi4B8gBaNsAnwKMfwJo D9AuBc4DxgFLAHKcDVwIrAEWAIcDF0TwLFwK0OD50BvhD4DVwKvAtsBpAMWvtY7wfAN0AHoC bwPrAJ5DIwHaVsBzns8f0zvgJ48sdzpg7Wx4KPIItiOekfN45TlONwNLAfaXfeE5QnsPOBX4 GuAxRwLk+1eA/WoDNItl9QgfnN3LNRk9ynbO7lWRn92z4jYemOFmaYAeRBlIYAZwccq6ob1c dEOuLIdrCOw19TkWoO9bW7ORj9f9oPGakAnkAt2BQcAIYBTwR6B1vFk4BXrJsYqMGceOY8ix 5JhybDnGHOs6W70yV1PrOYgvBrYBHgMeAmgDgP6eT2Q3uKcDPNk4S/MIwMbSKGzKPV/0307w bh4Ner538f8S4JOYeN5sw8DLwA8Ab8qdABrJ4Q3Y2jx4hgD9gA3AYsDaXHiGAjXVNxjprPNz gDfQ8wFrjOfNlcfjLBX7QGOZ2DZ0RlxXYCnAPv0bCFpN7aupPtaxN/AG0AMg7+cB/wR2B74E VgCbATSODwXRX4D9ALaZgqM98BHAeijCOEZPAbS+wK3AC8AJAG/YxwAUTuSE/H8MUDTdCKwC eIzg+cDwLIBCag7wKEBRcjrQFqBR6PG8WgcwP8c2D7gZeAVg/3jScwaOxrE4APgDcB3wAECu KO6uAsjzccC5wElArFVXnvztD+wC7AOw7GkAbWvgbOBiYAowAdgI8AI8DODxmsfC4bkGn6NQ KP0ZuN3CFe4nmT0qnk8LpX+d3aOcFws1ZaDVMYALUxpE1Fld23vXmbvwVag7bqFfmwoZgxmp PW8s8q5zNfKCfG/XmEETlYEIA+mNwERv1MGbG+1+4BPP9/t/1yOKooWg8NgL4A2IN/tNsYEo 3A54HVgDXAvwZs+bYB7AG7K1xfAwbx4QjEfQm1Xgzbym+gYgPRPgDZuC7yagFHgEYDkKlv8C xwMUJFsAecB6wBpnOXDPqxQONj7o5iFQXfuYVlN9GUh3Ac5kfQDQKHo+BsIAeb8ToJ0MTADe YgB2IZAHHAv8AlihdzX8SwHyQ3sJoKihkXdy8TRQBKwACgHat8BFni/6byi8uwGjgRIgH6C4 /TmCMXBZ55HA88AQgCKJIoX9fhlgOw8GZgDWzoTn78CcCM6By7E6H+B5abm4G37271kgaNWV H4tMLMNzh8a6TgCeAGg8BzjuacDpAM9z9mc8wL42i5WuWrYwq2f/EA7WC2tBVqWlpZGnNPhf LV2eUd1nslnapgdRBlqCgfx28kc81rtZHO/LDa+603DhvVYFUkuMRus4ZmMIqptB1ePAMuB/ wD+A4I0OQc94o7O2AB7eJHkzt9YbHnvT6wl/KfAngCJgO6A64zE7A/iseLYS/znb0QUoBjgT ZK0tPHMBziIwPWhtEJgH1FQfxYED8FgUKBRRJwKPAL0A2wbWcTBAEcA2BI+Vg3A5YG/Q8P7O ampfd+SuqT43UhvF5QiAN1kKiJ+BvYHBwGyAlgfMpCdi38Elbgc4+0JxZI312ONSXFmjiCJ3 8WxynMg8xM0HKKZo7CtFCY0zUYcC7wP7Ahz/HYBZQFBEUuxtBswArOXBE+zLU5EE9ncn4IpI OAMu64u1PETEK894nk/WeOxuNgD314i/DO4igGKKxvOWx2omGwA+3SLcQNrjvRhX4iTNxNm4 sqS84PRmaoAeRhlICAb4GC8tzfuRET/3vCrPwReL6/I3eNcXe41OiLZqI1KLAd4kN9UqUMEB AAXFKwBvZO2AWONjJGu8WS+3gYhbAPe8CCbCHRfxXwi3JtscicMDGRbAXwzwRs0bXH/AWh48 vAkzPhegELM2AJ6fgJrqG4n0joA1CgO2uwMwykbC5Yd2AcC0hUAeYC0PHgoa3nCrs5raV1t9 X6BSirk3AQd4DeBM0/bA1cC5gDUKCIpXa0Pg2RNYB4wHNgugH/xWBFrRhqh6G8UM602LlKTo ODnifwku274/MAkgfxwTtjEEWBsGz5c2EHFZb7AvYxDuC7AvFwC2L8zDY8RadeV5/D6BzLHH 3hQuAtU2itcTuhj0TNxAisVUHCeruhU2Ss1aiTKQ4Azkt5EdsQXChxBTE9DUnfAZWIq5+nPw q70tIKZeQJyKqQQfw2RvXvAm1dC+PImCBwErgMcBCoVsINaOjUTwhsRvDvaGyJkqzqTgG7Z8 FsESuHMj/s/h1mQ9kPgRQFHDmzRvnh8AxQAfHZ0OsJ8UCycDvFHzxvMtcCZAY9s4k8Vj1lTf MUi/G6AxP+t7BaB4exo4BKCxf5xZeQ94C9gdGAq0Aa4E2IaarKb21Vbfjaj4OoAi8yzgcGAq sD/wV2BrwNrb8OwL9AfSAPatO/AJMAqgiKKdCEwEarsgUVznADXZIiTOB/4YyXQa3EMjfvLP GZ8bgOcjcTwXFgBHR8IUSRzLWA7JC9uZBVA08bxcC3wMHAfwnCQeBy4DaLsBO3o+f5zilSdH pwAs6wAc4w+BRLRf2CjcSDbi/3Ml+qgvEcdI29TIDOTnyuZYJ/Wyky7f4gM6GheptfgMXLWu UAZfv0H+m1/zl9dGbo1W15oZSG+Ezt+DOsYB04Bc4CFgFRBreyLiB4A3xNuB6QDtYoA32SkM NMAmoswEgOUpCkLAEQCNbaNgWAx0BB4EmJd2OsCb7XlAZ4A37DAwEaiuvn8h7RWAfeWjpE8B 3sjLgKsAHu8WgGLmCmBDBPRPjviXwx0J1GanI0O89lGM1FQfhe2hwH8B9mcmwHEeBKwHrgWs zYaHgmEWsAyYDrwGVAD3AnOAeUBb4GSgNqPQ4NiyjzUZ2/AcQK6KAIoqay/CcwPwuo2AezPw NHA10Au4ESDnQaNQeg+gqGC/bwPIP4/BMSJvPDc4dudE/OfDXQd8DzwBvAvY8uwH2/YM8AEw F2B9dMcDrItGkUU/XZqN90O/D9v4xndNxUwjaQeiIetKwrMuidOWxj9m/Wo0cbLHi4uTTaOU gaoMXJMt/TMy5Dqc76fh05eGEwmzsnJPSaH8HR/eNVVza0gZaHoG7E1gU4/UCRXkATOAUiDW GNcbyAR4A+ONqrEtFxVuBvDG6cZU3g/hQiD2Q5aGuCEAb5K8CQettvpKkJniJWi8mbK+RQBm CaoY6+sG8IZdV6utfbXVx9mazQEKqQVAdTevzkijiOLYBK0rAhw3irJYARPMF/S3Q4B9Z301 Gc8F1r+0pkyBNIo6ikLyR2ETazyXiT4AxaHtqz3HWZZ+CsSajOXZpuA5ZMeVPLLuhLSsnsXn O072v8Nuwajw8m6TErCRdkzYNOunG8+fgM3XJiUCA3i01wtfEa/BWTMWawa5VrDcOPJoWVhu vLW4WT6fvI7wSyqvr3zqwGsel7TwSzuvpa9gRwE4aonOgIMTCHY0sBpYC/Aaz/tLMUDdQl1Q 58G0NxuUaVKzgirezFWTHlgrT3kGeA7b85jCh37rWj9JCOZjOOUso+Ong0165w7hVVtPTtDO BcUTBasNW78VsTY+QbuhzWoJBq5uK90zQ97s/Hm4D2ZDs/B8eS5cJvk3l9b6Rakxm8xriRVU XOJgBVUH+CmoXlNBBRaSwCKC6kg0lYKKEwpWUHFSoN6CiidFc9jNOAgVn5oy0JgMWJFkhROF FMGZPevaNJuXx6c/5ax87d6cWSP4rTmRzH7Ds0LJCijOYtJvXY6LFVVsvy1Hv1orZcCbkYKQ gog6G5/cHJwVPC/GhY1cf/OGKr/MbW6G7PlMl+etPZebux16vE1jwF5/OH7BMa13rc0lqG6q d8u0gDJQOwNWJFnxRCFFcOo2JUVT7ZQkXQ5ewPiohBc1gmZFFdPUWikD+dmShwd6l+MWdxZn pDwhZeS1sCs33FTkrYVMFGaskOL56z0iwsyHXn8SZXRqbgevMRwze/2x156aS1WT2lyCqprD a7Qy0GAG7AXLiimey0QG4OiUe4N5bdaCkRsP16KUc9wCB+cFjmEVVQFSWoM3vy32HUzDjJTx fn3NL0g8B8ZBSN0EIfVDAnHAdvEGbAUVz2HiOICP/7iuims/OWOcDfDaxGsUr1lqzccAx4ei iWPDtc98WsZ13Hy8x8d8dtx4zbHj2aDrjgoqMKiWlAzwZssLU1BQZSLMm7NacjHAm40VU7yQ WfDi1qALW3J1X1ubT6HRTo7AvM55OBNGRRgpxzqpZ3EG3IHdzWckGEvBc9TOTPGmzXU3vGnz WkQxSON5zB/12DgVVGSl+Yz8c4w4BgTXR1FQ0eVY2bVSdqbKXnfqfe1RQQU21ZKWASuqeOHi tz+KKd6c1ZKLATtmvIDxYmaRXL3Q1tabgfwc/Co3Q87GbNRYCKmerAAnwQb8exhzCv/O31j5 JoJ6192EBayYsucrb9b2hs2bM2/UVkzZeIopXqMYb788wKvWDAxwnDgOnImioKKICooqjhnj 7TgGBRXL1tlUUNWZKs2YYAzEiilerHjRqm1j0QTrhjYnMma8iPGCZsWUdZWg1GPAwWO9MZhb Phcf4kPRvTRPYhi8FcFgr8AN4NlUzAAAIABJREFU8nS+/zgm0XseFFS8IVMs8Z5q76tWTPHm zWsT4+2sOrxqzcSAvZZwBorjFBRVfPxnZ6msqGL+egkp5PfMDrwNq6sMJBMDQVHFC5bOUCXT 6EXbyhkqO91Olzcd/RYf5SclfPntZCuM6sl4rHciOtSXncIjPd7ExkFGP5i/wXtTBqOTwYJi ijMfdumBfZzH85gzH7wuWTFFwaWCCiQ0s1lBRYEbFFUcHztbxfMwdi1VvUWVCqpmHlk9XKMw wJuthb2Q8WJlRVWjHEQraTYGKIR5QeMFzt507PjSrfeFDWXUEoCBa3NlWIaRP2LjzWMhpLYJ NGm+91jPyKNYHxW7QXIgW0J7Y0UVz1Uab+BWUHHm3D7qs2LK5mNetaZnwI4Tx4WiygonuvZx H12Gma4zVCBBrXUxYG+4VlDxywHBm7NacjHAMeNjEY5frKBKrp5oax3sG7UDRvIQCKajIaI4 K+V9+8FdjZsnvlRh5JmbCr13cSazULY3aV6HeBO2IonxDBM8l+05rec1yGgh45jY8bJjQ8FL f3BmysbZGS2WqZdxsNWUgWRlgBcx+62PFyz7bTBZ+9Na223Hzd50OKb2BtVaOUmafudzp/Bc GY0GH4JBOwgj19NrvD+Ca/BY7w3EjVu6Xj58yJ8FSJq+1dBQ3mzZQ958rdmbNuN4c+b5HHtO s4zPDDxqzcIAx8XCiiUrrOjamSkbZ8eUZeplKqjqRZdmTlAG7CwVL156TifoINXQLI5Z8OZT Q1ZNamkGzsYXl165shNuUftgBmoftGd3SITKmWHchRYh7h23Qt5YXiQfp5CIiqXe3nCDN2B7 w7bXJIon+oNCSgVVLJNNG7bjRJfgGNGlgKLfunbsbD4k1c/05lM/vjR3YjFgL1L2omUvYonV Sm1NbQzot/jaGGrB9AvxGL1jrmyPm8UeaMYorIfaEx+4dnaexXunnpFJiHsbm2++nWCbbzYl c7zxWuNN2d6seWO21yZek2g27If0f0swEBRKVlTZMbMu2xXMV692qqCqF12aOQEZsBcqurx4 2QtYAjZVm1QNA3bcgmNZTVaNbmoGrsmRvhlpshuOsxtmoHbD3WUEXP7gwzMOEkTUDEiEj10j H5cVysTbRdZEklubY2++pIU3aZoVVPQz3lrQb+PUbT4GOFbWrN+OH+ODfpuvXq4KqnrRpZkT hAFemKqDCqoEGaR6NINjVt14Mt5e/OpRpWatjYF8fvnIlcHYVHMEZp22g2gaAaFE8bRZlbIG AsHIDxiESY4rn8L9JL9IllfJo4HYmzHP21iLFxebR8NNx0C860i8uAa3QAVVg6nTgsqAMqAM JAUDzjXZ0i8tU7YIGRmOFm+BO/sWEFFbw/Ue3dk7PcQU1etqiKyv4fkSAuvL4iL5+u8ihUnR 08RpZLwbdby4xGmxtmSTGVBBtckUagXKgDKgDLQ8A1e3kZ6ZaTIIc30D0ZpBwGBgcwI6iS/o rfIAKiKiFkM4TYW4mgJ3Snm5TLmlRBZ6efWfMqAM1IsBFVT1okszKwPKgDLQ/Azwl3XdsqVX Rob0xWO3vnhY1wciqC9EUH8Io0HwD6gUTfGaZ2QZpkdmQmzNxAO8GVjkM7Pckem3FUpBvOwa pwwoA/VnQAVV/TnTEsqAMqAMNAoD+XzkliU9KjKlOx6z9cBisu4QS90hlHpAIHWHUOqJ+L4Q Q93xOM5fH8jfRMKQXjnjRD8ez62COw9l5iE4D+XmYTOk2WmFMjNfZC3i1JQBZaAJGWg0QZWf K+/gA3+Q11bDzzYuCTB8wD23lrCLiwDzuZH8+PFIJByt63dpqJy/poiCiyf9Orx9JVCn56LO CtTmpaHeCi+MfEynH4313ch+FOgHNvPFxmyIR31R+PVVoKYwjm3jo37EsyzKhHkc5Anj26QX pt+LZzrLIw86FE2r8OoMo01eGlJ8F2EvLoRwme9n2CBsNqAO1INdycJFAPZ7YRkcWk0ZUAaa i4F8vvIoV9qHy6RDepp0gOxpj897R1xbOqENnfGB7AK3C8J0vTD9jMf1gu8x9DdPQ2SlRfye g38QR7xO/QrvYnz++ZjuVxxjMa4li+D/Beuc5uk6p0r21KMMtAgDjSaoqrTeEVwn8HEPWJUA 4uscjq0oTtnKw8RUWiUYCQTjrJ+NpdlwpT8Y4eWI/PO/JwZjfH8gvrJoII6ZvPhIXOSLpl+2 SgBR8Uam8ofLfhFctiutI3w3ALjoUniW40C+IDO+i4v37+LQb+4QS+FIAej7WS5ShvVUCjw/ LlqHLyory0A4RtNYB9KrHBNxzAMFSQHqIyIaeYw0tiUcSLN5GGv9FJUQkXhHScUvaPgMbAa5 AJRCTKopAzUx4ORjLyW8BTUn1EayM13Jwecru4JummSnwXVDSDPSFp+Jtjgf20LAtMX52w6f hbY4/7hw24vDQdohPRfx7fH56IA8HVDGE0UZlVtbVm0K8lUxG6aL8nzb/XIc7ze6qJvub/j8 LMcH+TekL3fD8uvsjbJ0nP/lDslqyoAykIgM2M92Y7bNqzM/oh1+irhbRtylEbdXxMUDfAfa IdTBD4dwdaG+CeVEwqW54uA6xfmrUJnxXegKL4xGhxhf6Wb6fkwvpTEeGsVzcRNPwwXUy8s4 pvMYuIDiWippyJiGKbE0VOTlRxrddIN4XOjScFFj/jSIFc9FTemVfkgf68esUTrLoT2UR/Sn Ma/n+hLJT3P8fN5xbHwkzivHOIb9Onw3Xlz8PKi2lRlmMdFjztZhKKSiDDfOzl26Sigdg56G IaALOBjoYJzDtDQ/jfm8MPMin5/m56ffCwfibXq8eCcU8o7rlXMifsR5YZvGMNJsHMvEBU4E fiK8tIhrw9Z1+IkJ5PFGn3EwlPRcpnvhiBsbNmSOBjfo96JIb7x4xrn4RT1RgUlg66dr4sRF 0l0vLyZqw2G54vLLZVCaPJ/tSGlmSMrx2a7Ae2hcnPQGH0i2lp9b/zPAvZCMtx9SJrpV1c9Z Iqb5+yVZfzbislGJJ3i8/jXFP4MvHiLrcOz1aO860LLOc/29mfj+ugJcR7hWaTXyFeD6U4AL TwHeXrg63xdUTdEqrVMZUAaamQH/KtvMB9XDNR0Dx0DM9YD4ggjF0wdJD+VKOmaG0vGtPMO7 MfHmlCnp+HbuhynUIDehGvk+NV8QIgyB6aWzjoiAjKYjDlogWp7iMxhmGSdQXyCMG8vvBCJu QH7d8QWin9+Ws3lYZyQON8yYecCm41drTk4GcI6V4Jwswfm3kS7CnhsTLsI5RWxAHk58bsC5 VYS8XhxmjIrwJawIn51CaOx1Za6s21gk6+/0X+ycnMRoq5UBZaDRGFBB1WhUakXNyAAFFIUW H7Lw5+Dt8K8zIjpDAHbDI8GnC1at9GZAOBvCmRDC4OVinj8Sx1kVt8JP82ZNbF7k89P8/N7s C9MC8Tbdc2PiOVNTWR/T7MwN6qhMq2UWp7IM7u7e7JCXH/6Iy/Qq8bjre2XgMp7mT9zREwlH 3N+FkcWb5WIhzgl5Dlzrh7qgvzKPn8ELV86qcRYvOMtWw+ybNxsYmS38x7/+hQ2S5JV0Rzak Q6xkQLQAxQhvTHelJORIGeA9WkYTyjHxVYrmlOGRWJnn0s/VhaFIuDziR7ikSEoxNbUxX1CG dKgpA8qAMtCEDKigakJyteomY+B3ggpH4ooyLiXjwt9xlY+tEFBLXAYiIg0Tq94jMf4SbT2w AeDaIgohrgWEelRTBpQBZSCxGdBHJYk9Ptq6BGNg5cqVMmPGDNm4EfNgasqAMqAMKAPKQIQB FVR6KigDdWBg8uTJsuWWW8qOO+4oRx99tHTu3Fmuv/76OpSsPsvs2bPlzTffjJvhyy+/lM03 3zxumo0cOnSo3HfffTbouSUlJZKbm1ttvcx0ySWXyN/+9rcq5TSgDCgDyoAyoAwoA62PAX4R 4CYSuUB3YBAwAhgF/BHAE7/Gs6VLl5p27dqZZ555prLSBQsWmM0228w89NBDlXH19Tz33HPm gAMOiFsMwsgsXrw4bpqNvO6668yoUaNs0HMh0EynTp1MaWlplfhgoKCgwKxevToY1WJ+jlVk zDh2HEOOJceUY8sx1i99IEFNGVAGEp8BvVgl/hhpC1uYgbvvvlv22msvOemkkypb0r9/f3nx xRela9euXlxRUZGMHTtW+vbtKxA58s0333jx06dPlzPOOEPuuOMOGThwoOywww4ybdo0mTVr llxzzTUyadIkufDCC70w67/33ntl5MiRMmfOHLniiiu8OiqwmP2vf/2rQMDJzjvvLE888YQX f8IJJ8hnn30mfAxp7dVXX5WjjjpKMjMzZfz48bLVVltJhw4dvFm1337jFkciEIbyyiuveP4l S5bI/vvv7824sRzbRquuP16i/lMGlAFlQBlQBpSBlGCgWWeoDj74YHPDDTfUOIsDMWSOOOII g/VV5vnnn/dmiTgTBMFk0tPTzZ///Gfz888/myOPPNIccsgh3gzSnXfeaSDUDGfA8EjRmwXj jNO7777rlRs2bJh3TAg6s8022xg8IjTvvfeeycnJMRBcXtp2221nHn74Yc9fXl5uunTpYiZM mGAWLVpkOnbsaCCqDASX+dOf/mQOPPBAL9/FF19srr32Ws//hz/8wWsb80PAGQg+L766/niJ jfgPZ6POUKXER1I7oQwoA8qAMpCMDDSroNpjjz0MRU11xsdnaWlpZv78+ZVZKIyefvppTxhR 5ITDYS/tiy++MEOGDPH8wUd+FFQUXqtWrfLSKMSsoNp2222rPG588sknzU8//eTlw8xXpVD6 6KOPTM+ePbGTQ4W55ZZbKuOZcfny5RQuZt26dcYKKgq8ELa3xQJ7r67i4mJz4403GgrB6vrj ZWzEf2wTwMe0+sgPJKgpA8pA8jKgj/ySd+y05c3EAB/VcZF4rEGQyFtvvSW//PILtodyvcdx fCxHfP3112IfsXXv3l0gULziWItV7S8E8/LyBOIr9jCC9VoyfPjwyvhTTz1VtthiCy98/PHH y8cffywQSsLHfcceeyx2eg8JxJ3XHluIbWjbtm2Vx4Osd8CAAZKd7W8kjpkvb7E6y9bUH1un usqAMqAMKANRBrg5opoyoAzUwADXIf3jH//gSvcqm1veeuut3i//KHYwu+SJGIoW2po1ayQr K8tbk0SBsynGX/stW7assooPP/zQ+wUg12v169dPdtppJ+9Xfa+//nrl2ij+IvHHH3+sLMO1 UmwbxaE11rtixQrhGi0KPjwy9NaF7brrrtX2x5ZVVxlQBpQBZaAqA5t2pa9al4aUgZRk4Nxz z5WMjAzJz88XPLrz+sjtDl577TVvwTlneXr37i14hOel4dd5ntDiDFZNRhFWl/2sDj30UK9u /HLPE1annXaaYH1UZdVcnI41Xp6A22WXXbx4rNMSCq+FCxd6YbZ39OjRVQQhxRjb/vLLL3t5 8CjRm3FraH8qG6QeZUAZUAaUAWVAGUgKBvhFoNm2TeCSIbv2qU2bNt52Cdwy4Y033qhcTYTH bt6CcMxWeYvLb775Zi+Na6Eww1WZD7+iM3369PHCXHPFevArQG9R+uDBgyvzBddQYXbJW5Te q1cvAxFk7rnnnsp89GCWyVt/hV8NVok/88wzDX7tZzDjZPA40UydOtVLt2uoGOA2C9wSYtCg Qd4xpkyZ4uWprj9eYiP+wzjqGqqk+MhpI5UBZaA2BpzaMmi6MpCADFBQVXmXH8JN/uoZ6Ahv PRPXF/HRWZV326EBnEHirBSET+V2CrVxx8dsZWVl3uO42vJy5ot12/VYteVnOh8Vrl27VrgJ aHXleHwshvfqDtbZkP4Ey9fFr6+eqQtLmkcZUAaSgQEVVMkwStrGWAZaRFDFNkLDm86ACqpN 51BrUAaUgcRgQNdQJcY4aCuUAWVAGVAGlAFlIIkZUEGVxIOnTVcGlAFlQBlQBpSBxGBABVVi jIO2ohUxgE02q/SWvxzk+qjqrLb0eOW4/ol7U6kpA8qAMqAMNA8DKqiah2c9ijLgMcANQrmn FY3v4OMmnfh1n+y9996eixcee2l1ST/55JO9d/Zxs1DuMcWtG/ALPk9IcW8pvArHW/BeWaF6 lAFlQBlQBpqMARVUTUatVqwMVGWAvw68/PLLvRcdM+Wqq67yNtCcO3eut9s694N69NFHvR3P 65LOPKxvw4YN3suM8ToawXsA5fHHHxds7+C99JgvZVZTBpQBZUAZaHoGVFA1Pcd6BGXAY4Bi p2vXrt6raRjBV7z06NHDE1UM40XH8tRTTwlfQUOrLd3LFPjHzT65yecnn3zixZ511lmCdxB6 O6EHsqlXGVAGlAFloAkY0FfPNAGpWqUyEI8BbOrp7Qdl044++mi55JJLvL2tDjzwQNlnn31k 3333tclSW3plxoiH9b/44oveYz9GdevWzRNTePFylff6xZbTsDKgDCgDysCmM6AzVJvOodag DNSJgZkzZ3qverGZzzvvPBk/frz3ypgrr7zSey/f4YcfLqtXr/ay1JbOTLfddpu3wSj3c9p+ ++29OjhLZY3rs4Lv9LPx6ioDyoAyoAw0LgMqqBqXT61NGaiWAe6ijtfOVEnnYnSueeLLiz/6 6COh6Lr++usr89SWzkXo3OWcKCoq8gRahw4dKsv3799f1q9fXxlWjzKgDCgDykDTMKCCqml4 1VqVgd8xwJch2y0T+LqX7OxsmTdvXmW+kSNHytixY2X27Nner/NqSreFcnJypEuXLh6YP9b4 S0K+7FhNGVAGlAFloGkZUEHVtPxq7cpAJQPbbrut8Bd9NLy02FvXxF/h8dd/tOLiYpkwYYIw X23pXoE6/FuwYIFsueWWdcipWZQBZUAZUAY2hQEVVJvCnpZVBurBwB577FEpqFjs4Ycflm++ +cb71d+OO+4ow4cPF/5Sz+5FVVt6bYfm5p4FBQU6Q1UbUZquDCgDykAjMKAvR24EErWKZmeA XwT4C9UsoA3QDmgPdAS6AOOMMXASy7jGaeutt5apU6dK+/Zsrgjbye0RCgsLZauttpK0tLQq ja4tvUrmmMC4cePkgw8+kEceeSQmJXGC+nLkxBkLbYkyoAxsGgMqqDaNPy3dMgwkpaAiVf/5 z3+8ReJXXHFFkzM3evRoefLJJ70d1Jv8YA08gAqqBhKnxZQBZSDhGNBHfgk3JNqgVGbgT3/6 kwwcOLDJu7h27VqhaOPraNSUAWVAGVAGmp4BnaFqeo71CI3PQL1nqLjwO+xWSIWJuJVhxFX6 3YDfjw/mp78iUgfLVBtGmotHeRXGr8P3M86vn+Wsn24w3fPjGHxgadPiuXwUyLzeXxW/X47x Xnokj/VzKJhmDcme2Tj7qDQaFuxz5edxBH+RgO+PxtPHNP75foTxF3JCQNAN+kNy1513ivTr +IakO8WSnrZRMkIb4ZZKmlMioVApCpehmnLUGYZb4bn0Ey4IppsWCXvxoTIwUCYm4lY45WIq EE4DwmWoF+HSMqnIKJONv5XJvXORP0AIAmrKgDKgDDSEARVUDWEt2cqMHJkueVhz1AbIBNKA EOAAGWVpnluRmSHp5VjA42BtUgbXJ/kwJqPSb+PosmwwHM9vcKSQVC3POCcQx3C8ssE4Hqu6 fAY9kkgbDeo1yBt2c9vmtvMEDUVUGAJHTRmongFTgrT4MLIxmuZsxLlbhIVvRTjnikVCvp9x LuIcIJRWhBMP8bJBHHedhIvWyx2TC1GHnoTVD4CmKAMpwUBTCapgvb7/GFyKaCtH+u7QQt9d U+JI224h6VSKy1IZbp25IWlX7sjGsCNpOSHJhuuUhaSsjSOZFb6/PAduOW7VLurIwGxFOAQd 4LtCtwJIC4kbws064k9z4HcRH0J8BfxwQ4gzAT/TXcQxnnm89Eg5G+8JApZzfSHg0E+REImj awUA/RQGzFvpjwiI2DC+Qnt5fSFh/daNihdbLig4vGNUI0zAImlv7cZZknScDmmYMfFcDL8f RlylPxTw+/HMXzXdr4NxflqcsHdqgXgMP/Px2FX9jPPrDc7gsD4vL9rJD0cwreosD053b9aH c0D4q8bPMnbWyPp5HrCMNWTxzMYxPy0ahnTALFZ0xsqf0mI43uxWNJ9fJjq7xhkzfzYu6F5y 6aUiAzs9LVnpGyUTM1KZ6eX4SJdLZpoL0kBciA2KiPs457j9PBgT+Yw4+KGCJ7AhtCm2nUx0 BqLe+H7vCwLibNjxftjALjedcdrPE2LOOhyXu6xaICxrEYet8UMFnmtc+lfj+rNanHCBFMtq ufNLijo1ZUAZSHAGolfWTW3o30a9g4vGQZtajZZvCgaM/4jEeyQSeDxinKqPUKqkV1PGz+M/ gqmSP1Av4+3jGTfyuCYYR79BvM1j6zExdQTjQ5HHO3hu4009FeFJzZqSNFmzMR1ulqwtaSOF ZW2ltLwDwo8Xriv0BJMVT1YoNAW7WmfDGYiMyzGoAYKC4sITGxvgYgZISgGeu005u+PI6SOz 8PvQbMiubEi2bEl3c3BuYpdUJ9t36QeMyRHjtIVKbYvzty0UL1w3GhbECdMNfnnq4GecBoBr TK6nbFFJA60YdfyGtvyG4/6GOn2/izhB2IFrzK/yc8ESGfcTH2GqKQPKQAswwG91jW92IQZr dpzoV1ovHPlea7/KMt3z4+urlxcuw9X5MY+OCwjqhGvL0Y8rmxcXdL0bdiTNEw/Mg4uzQyHh HYeCgnF0gUi89XvlmQ/x9Bvc1D03EOYFvzIt5OehMAjGMQ/L2rw2zHxWKDhpfrpdF8I8TKsi MiJiwouDny6RXoF8Lo+BdSUVEBzlYSktDsvyuWEZ5/UNh04pw0yjN2sRu20ChZ43I9cuKyel OqydaTIGjDwx0T7ua6qDOHLFH7C1R0YHSatoj8eC7XHJgut0wNWnI65HXYDOuCZ1xucZLuBw +49InDhtkD4A8QMQHzVv8o5BRDJ+825Grhu1EnUsRl2/Iu5X1L8Yx1qMyfdfcG2YJ7d9vjJa gfqUAWWgMRkIfjwbs16tSxloSgaqE1QJvQ9VUxKSrHUnwAxV4lN33sh20rmsu5j07ngMCpeQ 7hBkvutID3SiD0RULyirmr8kG4P1XM4vyAvIPA+O+VnCJTPk1q8546WmDCgDDWRABVUDidNi LcqACqoWpb/xDq6CqvG4RE0hzIT1wBq0PpjRAtIosvrC3x8CbCD8A+HvVO0RjVmDtBnATMx2 z8Ay0xkSLp6qQqtaxjRBGajCgAqqKnRoIEkYUEGVJANVWzNVUNXGUCOnX7lHJ8nIgLiqGAT9 BYElgzFjNRwCani1YsuYZWjF98AULC2Ygt8AfS+3T1zQyC3T6pSBpGdABVXSD2Gr7IAKqhQZ dhVUCTSQfxnZQ3IgrFxnC8x1QWTJVhBb20F0dYjTyhUQYV8CX4gTmiSLzeTIWrQ4WTVKGWgd DKigah3jnGq9VEGVIiOqgirhB9KRa3fHjFbmCPwYaAQEFlxnB7R6s5iW49eFBrNYzidY/D5B 1i39Apum8leaaspAq2FABVWrGeqU6qgKqhQZThVUSTqQV+4xEPv/7g5xtTt68AcAs1mY17Jm DPbOcj7HI8IJ+PH0eLnpf9NskrrKQKoyoIIqVUc2tfulgipFxlcFVYoM5IW7tJdObXbDI8DR eEQ4Go8Lt4XYit5fjCzEDNfrmMV6Qz6D0Jo4kfuLqSkDKcVA9IRPqW5pZ1KcARVUKTLAKqhS ZCBju3HVnt2w39Y+2BVuDMTVQRBXPQNZViPubeyP9QLE1YcqrgLMqDepGVBBldTD12obr4Iq RYZeBVWKDGTN3XDkb6N2xuzUEch2OMTV8Gh2swqPBsfh0eDTctOnX0bj1acMJB8DKqiSb8y0 xf5aDW5gGLtTum7smWRnhwqqJBuwxmjuVXsMlbR0vN3VOQGPB7eMVmlm4YWPj4lb8pTufRVl RX3Jw4AKquQZK21plAGdoYpykdQ+FVRJPXyb3vir99wGL8A+CbNUpwQeC/J9hM9K2Pxbbp34 46YfRGtQBpqHARVUzcOzHqVxGVBB1bh8tlhtKqhajPrEOvAxWG01bOSBmLEaC2F1KBrHzzie EpoPsJj9X3Ljpx96Yf2nDCQwAyqoEnhwtGnVMqCCqlpqkitBBVVyjVeztJZbMmRmXIyF62dC YLX1jmnMD3jR87/kC8xc6S8Em2UY9CD1Z0AFVf050xItz4AKqpYfg0ZpgQqqRqExNSvxXpOT /ifMWF2IDuLFzzBj5oi4+XLTZy8g5Hpxifkv3r01Xlxitj41W2XidCteXJxsdYvSAa4bT5or sRjgeVvdovTOSHvFmEb9nCRW71OoNRFBdTS6tBpYC6wHNgDFAHfa5n5FOpggodXa2TtkSPe2 WMCedg04GOrzYLC2yrlSbvzknQThhdckez+N9dsm2nQbVrd5GQheR6yfbjx/g1qmA9wg2rRQ CzPA89YKqhz42wHtAb5zjILqNRVUYCEJLCKojkRTKajWAVZQYadtFVTgQM0y4K2z2vtUCTnX QbvkedFGPsaLni/HjNUUL9z8/4LiiTPnDFvX+tmqYD6G1ZqfgaB44uymDVs/XZqN90P1+M9B VlMGko0BnrcUVJmAFVS58FNQdQLeVEEFFpLAIoLqMDR1DUBBVQhwhoqCir/20hkqkKAWYOCY LTNlWLdzfWGFL1D8sDvOExIuvqqZt1uwIokuRZRFWsRP16bZvIiqnMmiX63pGYidgbICqgKH pt+69Nu0BokqDrKaMpBsDPC8DQqqNghzloqCintR8TGAntsgIQmMF66DAT7uo6Cyj/tUUIEM tRoYuHhkR8xLXyvGuQCfdu5Jtx77WN0oKwrvkYcml9dQsrGS7EwUXYonC57Lev1pLJabth5e f3jPoKiysKKKbr1MB71edGnmBGHACqoMtCcboKDir4E4S8UPB2epKK74GJDxTGc+5qcQ4wVQ rfkY4IWJM028yZUAXB8W2QtWAAAgAElEQVRVBPDxHkUUZ6d4E+LsFOOZznzMrzNUIEGtBgau 3X2QOJl3RrZb4AObnzFrdYHcPHFCDaU2NYnXIMKKKF5XCF5j/r+984Czorrf/tCrYlesiyDW xBaTVw0BrIklNjRKLMH2+auxi7HiHwFbsGEhRo311dhFo9FoANFoXkussSQYwBqxGwUBcd7n O8wPx5t7L3fXZd1ln9/n891z5pwzZ2aeMzvnuefevTvdK+RSoQVEvkK+nE41njU8b8JY1XuV yoaqeQ36czqds8QNYqLoJfg3DUwwBK/CmGiWFUeLH4r+ohjsywS2t4j+VlZ+pCB4ABDcNMQo 8bQYx0ZJcCzeUmtuEQ8yHl5owjlimjBUYaowU6xaYaio5+1B4PptqCRCEwb3I/cbb+EBq08Y J1ajMFVhpjBU3Ovx+SkecuzHg81hBaorMGzgtrpTLpTNWTNrmCY361vXj0lGPfZm9R0bVMsz JFamwkjxfOF59JoNVYM0bfKdckO1qg7MH8DwbApjxXOH5xbUHDZUNUvVJA3DAGGKJor1xaXi ZEEUDdUK2n5W8E9HpwuCX+h3xV7iXlHsT5tZjNFPzMeB8zazn3yG5QyxXqGsuWcxRhgqrjlW qbiu+IB60UxRTzvas5/ve4nQhIEh4gHFw4qHFka91FTFW30YKurj4cZ+DitQmwLZXwQuzovN Yfot14up9FNNif+bPCKj1bjfX1Vqpng285yBf9hQSYUWELmh6qtT5ZkDGKtSU6Wi2gJn7Wi+ CpyjUxsqrhb/FMV4QRsvip3Fb/OKLZVyMzyQby/qCRN1cfUDs8Q9Hfc1kzETM5M3horyeGWp rKOJFIhXeiynMx4QpioMVLxCjFeGXpVqosFZpA4z77NT5yQn/+jGpG1b3gbcTb/xo5Mfpb9I Nh9wSDJq4iONdL28KAtTxQu1eHHXHFf0G+mSF9luGLOYR+JZFWm9Ljomnnrt5MZNpsDrOtJo cZH4cZmj3qCy3UQYql2Vv1VgquobfOZoz5KdMHFPlZQ1l82imeJ64+FGSjB5M0ljpMJMYbhs qCRCE0c8nDBLRVPF+ISxwmQxjmBTJREc30CBUZN4dg5KThnwY/3G6/nZZr2kbTopGTbg2mTG 7OOT0Y/Gqv43OEi20h3PHZ4xsUr1Tfr0vk2vAKuKPJfi+cSYNuhdDBuqph+8+h7xXO2wv9hF 8DZeMX6vjeFiSfGJ2EnsLhoS9HFwyY53aru5GipOtdRUxS8BE3gYqnj1WDRT0Y4+HAtfgRgn xoWHVhgn0liZIrWZkgiORlRg5MT7ksP7rJf0WPkEGasTNE/ul3TtuFNy6oBTk5cnjk1uye7H +h6Q50cQhornS5iq+vbn9t+uAhhhXtDxDIp5IsaXtObVchsqqdXMg0E+UlwiJopiTNEGhmdH MU3QdpJoSEzVTls0ZMdvaZ+YpLnhmaRJCcrZBn45uMdJS39RVORoIgUYkxivGJt4RVhcmYqy WNFiH4cV+GYKXDRZz8XJw5NTNrs+adNpjN4G3E5Pi4uStQYcnAxLj9Q/Xp7QgAPwvIEwVDxn gMnZ0bIUYMz4WEjMFYxpjG+9roQOHM1fgXt0ioeIk8qc6o0q422/KeIm0VomIa6Tm57JN4Ky mIyZnItGqvhLwn6OplOAcQlifMJYkcbKVJTFmLKPwwo0jgIjH31VHW2fDBvISv55Mlbf0SNk vFarbkvSL4cmIydNKXugUwacpvWLK5NzJr5RUh+GKkxVrIaXNPNmM1cgxi1edMdcUe/TtqGq t2Tf2g5H6chPlzn6zSo7Q3ws+Gu9hgY301Jldv5QZc11YovzKk7AMWHHQy4eeqRhpCItc7ku WggKxDiRAmNEioEiH2mMXbRTlcMKNLICp08Yp7cB70t6rHSMvm39pOyD623a7Shjdam+tGNU cu7E9+Yf8cR+y2ZtOutjFycO2DY5c+LL8+u+ysSzhmeo59SvdGkpOcas+OK7weftwW+wdE2+ 42Qdka88KF2l+rfK/ipWEd/k805raf/3RWn0UAGfz2qOwcQbwaQckzUTcxgoHnZEbM/b8s9v Q4GiUQpTFWMWKedVbPdtnKePuagrMO9twDOT4ze/JunU8Uw9HfaWsTpKX7Swvz7Ifk4ye86Y 5Jy//Cdp336IpOCzUavq7/geTk7ut30y6uEncnnimULKcyaMVV7tpIUoULoyFeNa79NnR4cV WBQUKP4SlObj+ny/hxLfTopRioh80TwV89HOqRVY+Aqc1O+7Sbt2Z8lU/SQ/2Af6tnW+duEX 2u49/wRSfSFtOndXvT04QWV89qb43XdLaJtV/tv8PVRSoQVE/j1UfGTmA/GRYPEgvhOPzyTz 0ZF4VilbPTzBVNfHtS1XgXL3drmylnuFLe/Myz2YypW1vCvzGS8aCpwyYIDe4huui/lRxQtK 0znJnC+HJGdNukttSg3V0iq7xYaqonrNqiI3VPxlPO/OVDJUrKbXFJ5gapLJjayAFbACVqDV KHDqwP56G5DPpy5X9ppxTLO+GJqc88j1que/MvCvrlihsqGSCC0lGttQ8Z6vwwpYAStgBayA FQgFZs56SW/5LSkqr6B27jA6Oe6Hx8cuTq2ADVXruAd45aQ/ES77V3ytQwFfpRVoWgVO1eHu zA95mFIm5i3y7UjGKcPXoawv+KOKFUQxdtEGf73bWUR/qyvPd3fF93fRb2w/rzzBZz8oL2UH Kh01KNC54xB9fqqDKP8uTpR37XBMcuxmI9Rj+XY1HMpNFh0FFrah2lRSlfsz02+q4Erq4LaS TnjPm+XXInx6n+grLhR80/hQUbzunbTN9zfxfU7biIhq/dFH8ThH5zvxIcViOfnNCnX6pt7k j+JiwTVEbKjMdeIBcbhYVkRUOj+OVam/2Hc/ZTjeuYL3iW8QfxP0ubACrSt9fcPCuh/e0DEx jA4r0FwV4PMZFwm+86Y0nlXBK2KXkgq27xCfF8r/pXzHHAwaH6KN7eLvwLoqZ5Iv8gdtOxas QBsZqYMW3Cxv0a3TXsmxm5+ddGtfbmxr7sYNW74C7RfyJTB5b9WIx1hMfe0t9hF9SvodoG0e WvcVyvkwGe9v8+HBB8XJYrjAsLBU21/8RlD+qrhe/Ew8KgaIcv2pOMGojBT8NQDBVxcQq4v1 xCls5DEtT3+t9HsCE7SxmCB46PGhRozU78R5glesO4stRbXzq9TfHO1H8PCeLLYXPQXXfLpY SaAB3wz7J9HYwbXtK9C8NBr7foj+Ma0xBlHm1Ao0JwUm6WS6iSPF6DInxgu63cTYvI7JeUfB 86ghkTZkJ+8jBU78/lL6os8rk7RNx6RNKrOqNFHapq3GJN9Ov+ysNcXOekuwk9YBuyTt2iyR DN5g7+TyJ8s99yyrFai3AkdrjxfEFHFcvjfm4oY8P0zpoYJVorfEBaK9IPqJa7LcVz/6Kls0 JtSsKM4XPHymi2Jcq41tigV5nofUXwvlmJT3RVvBytSxIuJiZS7PNyr110b1b8cOJekO2o79 i1WslM0WqxQKOf+txbbiL4XyFZTHCC4jKp1ftf7oipWg/0tG8RPxsDhMoPEYgcG6XURgsu4X HwjK1xcEE8AV4nUxQXxfEN8VV4lfiX+JpwT7rJVvf6z0onyb8zhcTBTF+4FrOFugw+PiF4Lz eFIsISIwvLxSZ7wwsdw7bwruDcaCuFP0znLzDOTLynPOXGuXvJxzfkhQfrVYXJQLDGi5/bm3 uL+5ttvE8oI4RgwVNwtMOUZ9L/GKeFZ8TzhanwKn6pK5Lwl+98aJdcQHgucYQdkhWS5J1lA6 Ryydb3O/vSPa5dvF/vKi7LnJ/Vgas1TAc23PAjuXNvJ2gxXgWdRRLCZ4DvDs2VAMFIOEPnnl aAkKMFb5mDF2jCFjyZgytowxY11z1KtxlV6ZSPcXmANWJ3gV1ldwUhsJgu0zBJPo1mIbsZ0g 5goeAsXgouivGG9p42hxXrEwzyMEx35G3Cc2EUQfQVkEk95SAsPCPqV1PNiISv31VN0X4lbx vPiNWFIQHIv9HhaYBB6kxKriU/E6G3lMVoomj4ld8zKSfuIl8Z6gr3LnV60/7ZLpdhMZxa/E QeISUSfQhod6PLiVzYzby0oxRf8UVwriMkE7xoo8+6IdRmtvwcTwYzFNYHb+JcYIzvkM0VX8 VOwiGPfi/YA27Lu5GCYuFV1EJ0E5Qft9BRodKrgffiC2ED8X+wkC08KxVhNcNwaHc+YeOEIs Lv4sxgn0xdxeK0qj0v6rqCH9cu8xJu+KqwRB3UnidsEkdpbg2vYRj4jThcMKoMCLgvtmNBsl we8dvzf8vhA8E24Rc9loQOyufQ4uwP3osAJWYCEq0L6R+mZiXU4sKzATm4pPRHHS1ma2QvIQ GQUTz/biLvFojpIGx+rak4mXiX9P8WexjqgTnEvEm8qkopuoEx+LCAxP93yjWn+0uVN8KFgp +b1gsu8lOgoMwlpihJglXhXF42gzeUNwDpxbnN9g5S8WhwmiThT3i/MrLVez+f2R7y1uEyuI lQVmqZ1YV0wUm4k/CaKvYLy2Ep+L/xWYvyUFOvYRUwUm72CxnYjrOUb5uYIJ4moxW7wjZoi3 RU/RWfBwf19wnIj9lTlHMJHA/wi0w7jsKNCUYz0q/i0OFBcKNCAuEXuJq0UEJu9BcXdecLjS OrGHwOydJ4iTxFsC/T8TEZX230cNuLceyBueppRzwqgRaM35Elz/WPG4QPPrhMMKhALDlXlF DIiCQnqj8ruJa8ROYpBoaAzRjvzOOqyAFWgiBdo30nHGq59rxSTxruCBMFKUBhNnxBRljo+N QsrEtJ7oKpYXLwiCVa8/Z7nyP1ZUMUaJeERsL3YQTO5FY9dF23MEEzN1y4gIJtjJ+Ual/n6j +qVEHIvr/X+CY3CObQR1aLK6GCyYwIvnoM3s+jAmRCdxg/iO4LyZvIlK5zdTddX6e0P1Kwk0 pm/g4Ux5D3GiOEIQdYJ2mCmCvkeIjUVbgTGIQJ97BOeNcZgriE8FupaLqSp8v0xFncqKD3zu H4KxQc/2YmdxoyDqBOURGKRlYyNP65QW+3xS23CWQNvpIoJrQ8OioarTdrn9L1d5UQeunf3i +OgaMVuZF/MN9MEkOqxAKMCLpxPExeK1KMzTm5SOFNuKWYIXEw4rYAVaiAJMKo0RTNKnCSaY X4p9xE6iNBYrFDDBMTGVxtkqOFSwmsDETR5YDq8UHH9goRJDM1UwkU8TdSKiTpl/iC8ED7TV RESdMkyG1fpbS/Vri4ipymB8MCIDxBIiAqPCOXAcrh0jFtFLmb8LjMPN4j2BJo+JiErnV60/ 9r1PsHqD0eEBfY/oIG4R48RV4mVBkC4nWE0haMdKDStjaMR5Ug8ri7GC+HJe0uCfHLdnYe+t lV9F/FNMFVuILcXtgkArjh+xpjJFrSjHDBX7XEPb/QTX8icR10G6qsBUF6PS/qXHxqx+JjB1 xDfVYl4v/tlaFLhWF4qx2qrkgt/U9uPiIsELS55jDQ2eQzxvinRqaGfezwpYgQUr0HbBTWpq sbtaXSJYXfijYFWgaB60mcWu+omB6C52E48IgsktDNjTyk8SzwomQvKAMakUM1Vxndghb7CJ UlZYOJe7xWair+gqThDxyu9O5X8h0IHJFyNBXbX+VlD9nwWmq534pbhfzBDocKEglhH0d5t4 Szwh9hfEHoL6yWIb0UcMFfTHOUIbUen8qvWn3bIPX3dQyirUbwUP7qvFKMHxuIaI15TB+A3K C/ZTumNe9qbSwXk5ZufvAiNTLb5QZZdqDfI6xoW+echjgq4RHwniJnGOwDB9KIg/iH1EZ4E2 jPUDohi02VKsJtCSsVheTBADBfcZwXEnilRgjnYRRKX9Kd9a0C/xU/GgYH+HFaivAtw3hwvu 0dK4QQW9xY2lFfXcflTteWYW4XnksAJNosCnn36azJ07NzsWKduO2hTAXLwqpgomwYcEbw9t KliJIK4XEwSv6t8WfxYYBwKD8XqW++pHP2Uf/mrzazkM0/Svlcz78DJ9Pytmi6MK9Ty8/iM4 LoaN8yU6CkwXxuEzMVpE7KtMpf6uy+umKeW8MW/E6oL+OQf6u1egA7GO+LegT4zDloIYIXjA lkJf1c6vUn/aLYu2+nmqYOLHWJwkrhZ3ic1FMXbUBvpMFpz7BoLAhLwnXhTUnywIxvX5LDfv x3eVoANRJ94RvxMbiX+KiOL9sKIKORbaoyNjFFGnDHrsGQVKVxacxxuCewqTE8aNsu8IYqzA EKPznaKdIEaKWYI+OB73F4E5Kt5Llfa/Uu3Yn/t7ilhfEOeLYVlu3g/63jDf/r5SDKvDCliB RUcBnq08mxcTy4vegt/5gWKQaFZ/4Pbaa69lc8uSSy6ZLrXUUmnXrl3TtdZaK73rrrsa9TxX Wmml9Lnnnsv6PPzww9NVVlklff3119Nx48alq622WnrllVc26vEaozPGKh8zxo4xZCwZU8aW MWasv5Xg4OsJTqZcYKgOERgMJtOFEVz8miIm2uIxEGj1YkEhv6rySxa2I7ug/hC/nOD0t1x0 UkiZ3HnLsH2hrJZspfOrpb82OkAvgQHoVOVgjF+5cWEfDNMyVfYtreqggjCSpXWl26uogOuo JeJ6y51ncX9WR3sUC/I814AOXGu1qLR/T+20tqj1fKsdw3VWwAq0TAV45vMMaVGGatasWZkH 0WpROmLEiMxczZkzpzF8SdbHtGnT0jhG9+7d01deeSUrHzJkSDpy5MhGO05jdqQxbLaGakG/ GmGoFtTO9VbAClgBK2AFmqsCLdpQYUjGjx8/31C99NJL6eDBg9MxY8ak/fv3z/zKvffem+VZ Zfr5z3+evvvuu1n5ueeem15yySXpoEGD0hVXXDHdY4890pkzZ2Z1O+20Uzp58uSsfdu2bdNN NtkkHT16dLrsssumvXr1Sq+77rqsXXP6oRusxRqqXXXy32uuvyE+LytgBayAFbACNSjQIg3V 5Zdfnl511VUppmjddddNR40alXmbp556KmVFaeDAgSlG6ssvv8zq77777vSdd97JDNIpp5yS tT3qqKPSHj16pLfeemv60EMPpXV1dem1116b1cVbfrzF2Llz5/SJJ55Ip0+fnu6yyy7p8OHD 0w8//LA5eansXDTWjWqo6vvWUw33WsUmt1escYUVsAJWwArUqgBvk3cXU8Tnte7kdq1bgQce eCDRylGiFaXkk08+SZ555plE5ikT5fPPP09uueWWZOmll05mzJiRjB07NunXr18ye/bspE+f Pslf//rX+eJpVSrZbbfdsu2dd945efnl+Jj0vCZa1dK/QmyTyGwlyyyzTLLYYoslWqVKllhi ifl9LKqZpjRUi6qGvi4r0FoUeEMX+hNR/IOExrj2y9TJpeLZvDM+t8cfARSD+kcFdUeL/uJV cabgDxuIvuIwsYaYIM4VzBgL6q/SsX6kfQ8WxdhPG3NFpWPRdn+xi5ghbhT3iDmiIeeu3bJY XD9HiZXEa4L+thRTxVCBFo0dfP7yl+I3guOVxsK4H/gjj0/FqaUH8/Y3U0BvuSUdO3bMOsE0 bbDBBsnDDz+cGR7MD2aK6NKlS/Lkk08mBx10UPLxxx8nemsvM0RZpX6wHdGtW7fMgMV2a09Z unRYAStgBWpRYDM1eqWWhjW22VHtfiswLcWXr6trmz9w+X2BacoTvxb8ZeaZAhOBceKPIFix uUvwBwMni37iLEFU669a3QDt+5EongcGrdqxfqb608Rt4mIxXOwviIacO/txvHHiBsFHJ64V 54kBAuNxpSjqp81GibbqZYzACJaLxr4fOMYIwbU5FqIC+ku/bAXp2WfjNcxXB8NknX322ck9 99yTvP3228mRRx6ZrThFC1a5HOUVsDLldXGpFWjNCrAy80fxrrhZxGTN5LqK+KG4QLAC9LoY L+pExL3KrBUbeXqR0tK/vPyOyvh6kf/kbSLprcwT4g8FWIXCLP2PwLRMEqxmcG4DxLbiI/FL 8bTg3A4QPOMq9aeqqnV9VI9JK55Hqu1qx9pa9ZzX1eJhcYXYQzT03LVrZsrQ/jExVhwoWKXD 6C0l7hCsHBIc52zBV4E8Ln4hIjCuL+YcEYVKGeudxZNiikBDgn4JrqOrwNTtIhgbxi7uB2Wz //DAez+v5+VdlF4nBokI8pfmG9sofUF8LG4Tywtib7Fblpu3Gne/8h+I28X6eXk3pejKsTDU 3xflgtW8cvv3VDljyrGfEQME8V1xozhRTBa3Co75kMDQHytabHz22WfZapI+15QZJozTdttt 91/Xw1t466+/ftK7d+/kiy++SG666Sa+B+K/2rngvxXgYeOwAlbAChQVwPyMFkxUPCMOE8T3 BBMrk/jhAgPzQ/EPMVJE8LkeVnKKwWTKJFuMM7RxtGDCLAZGprd4WGAK4virKv+pYCKNYOLr K9iHyTHiVWU4z2VEpf5oW62Oc9hX0O99YhNBVDvWMNVfnrWa96OfEq6joedOL/3FOLGC2FQc KhgfVogwWdPFcoJAqx+LzQXngoHhfHcSGAX0xpAeIn4uCMwRdUME/V4oGOcjBbGfmCnWE6PE NWKqiPthNeVvErz1iFFCpyPEP8VgEbGPMi8ITDntORc0fldcJYhegv4I2mDSMDX0daUgLhNL C45FnrFhrEuj0v6UPy/qxEiBoUPbbmJ3gbnjvHlRMEmgB5r/WiwmWmToO6gS3qJbeeWVk+uv vz65+uqrs89HlV7M7rvvnkydOjXZeOONk/XWWy/7LNXTTz+d6PukSpt62wpYAStgBaoo0EF1 bwsmEPKLi5UF8YZg8v2peFO0EQQTEZN6tRdo9MmkVS6mqrB/oYIJ7BGxheA83hcHioFiiijG zdo4XowV5xQqOLcvRS9RqT+aV6vjnDEYmKJLxCcCLaodS9VZdNXP34hpAgPR0HPXrvM/W3aY 8mdToNhB3J7l5p0PppLA/IVRYntfsY74kzhORLDSFzMk47p1VChlbDEx7UQqugviVcE4RLAf 98PJ4s4oVIrRGiTWFP8RnQR6oN+y4iRxr4jAwHAc7rXzxQjB9cwVnQXRRZwqlhRfiDoRMV6Z vWMjTyvtv4bq6ZdjRTykzAFiU/GhiPt4jPKhkbLZ/b9RXt9RKeaKc8cUbigYY6672f01W0NO iK9AiO+p0mep5n89QkP6aq77MFb5mDF2jCFjyZgytoxx3AvKLjjaL7iJW1gBK9CKFJijaz1Y nCeYvG8Vp4vSmKwCHkbEZwLzwiv6F0XEEGWOzTeWUTpRMBkymWKCKsWRqmgj6J/JcnXBigET MSsTxWCiZqLnIVisYwLmWl4Xlfq7YgF1K6o+rvER5bcXGJkZotKxVJWsK/4gnhQ8pD8QK4ni PtrMTMaCzp12aEsw2dMfD/k9xCuiv+gj/iGIOvESmTyuzVPabCJC9w7Kv5zXkbxVyH+qPPqV i6fKFNaprHhMrhsI7hMmK8bpUfGu6CUeFxHvKMM9hNmKqFNmivg8L5ipdITYWHD9xf27afse UYw6bZTbfxuVc92Yu4h/KbOceFFgokPvWcr/XURw76Jbqwje8otYfPGi/4xSp6UKcGM6rIAV sAKhQEdlmPh4Jb+5YGIdJUqDV3ARTEYYmn9HQZ4+oPTQHCawE/P875RWiwGqXKLQgInxffGa 4LhLiQgmZya9aaJORNQpg8lgEhwgyvWn4op1PVQ3kAZ5pEqnCs6j2rEwLneJoWJ3gZkiGnru 7PsXgZmj3zbiDoHh3UhgMg8REZiFnrGhdGuxivhY/FIwVkAb+owIExHblVJ0KA3MVPGY3Dv9 8kY3Kd1B7CxuzMsYr5XzPAlm8zOBsYngOjjPdnlBB6V7C66DMe0l4lroa6woRqX9OTbn2rbQ eE3lH8u35xbKnbUC9VKgeFPVa0c3tgJWYJFUgJeiTwsMxXOCCXEpURrrqgCIfQSTapiHvZRn NeYNMSlntlImLbaZ7KoFRuTCvAErW0ykt4m3xBNif0HsIaifLO4Wm4m+gtWQEwTGkKjUX7W6 maq8TmAGiE0EqyN/FNWOdbLq0exewXkAb1s19Ny1a7ZCOEzp2uIAsZN4RmwrfiW+IyI4t8Gi k8A4XCM+EuPFzwTnAleJY0W1wDxhtLiGasFq3JZiNYEBYuyWF8TNYkexlcAIErTH6NGe+Kl4 UHC8iNeUmSIG5QX7KaUfyt4UXCOBWcQkrcmGgnsCo1Vpf/adKnYTBPuvIeJeocxhBayAFbAC VqBRFBirXj4TTMKYqi0EgUFi8mYCfEUwkWGOpgpWsyKYGP9PbOTp20pXKCmLzanK9I8NpasL TN2zgvPAnHQTxDqClbB/CYwCE3nE4cr8R3As9u8hiGr9VavbV/tyHM4DQ3iUiKh0LPTg+os8 le/UkHOP42ESMCS3iNPFGQLjdrkI86Js9v84OV+MAytpnCeBKf6LQJt3xJ8E5plgXDFrEYxt jB/aYwbR/1WxgYiI+4Ft7pmZAr3uFBiriMeVuS028vRKpbPEY2KKWF8Q54sRWW6egWI8Mcxc Uxx7oPLviRcF9ZjYCPqMe2lH5cvtv6vKua+eFmgRGm2q/PMi4tfKoHPEVGV+INqKjmIxgfa9 xYaC88IANtePDPm8ShRgrPIxY+wYQ8aSMWVsGWPG2mEFrIAV+EYK1Gnv4iRb7AxDNV7wsFld tBELI1ZVpxiJ0mCyXku0L63QNg9CzqlcVOqPtpXquMY1RRcalUS1Y5U0nb/Z0HOPDjopg/no JarpzsoLxyoG7fvkFMsXlF9iQQ3yekxbjxrb0qyn4B4rPU/qIpjUVoyNQooO3xXLFMrKZSvt j0Fk/+7ldlpAGfdEizdU/I++Dh06pPrLv1TfS5X9bz5951T60UcfZbbjBz/4QVanvw5M9W3n ac+ePdNjjz021VcppPpi0LRv377pEUcc8TWLss0226R77rnn18qa84bG0YZqATe7q62AFVi4 CoShWrhHce9WoNuquyMAAAglSURBVHkqsMgYqhNPPHG+3+F/7a2xxhrp+eefn5VhqIr/0Fj/ qibVN62n9913X1avf0eTGbIJEyZk25dddllmut5///1suyX80O3VqIaKG8NhBayAFaiPAq+o 8TX12cFtrYAVaN4K8L/29tprr0QGqeyJrr322tn/5uP/9BEyXMnQoUOTIUOGJC+88EJy3HHH JVdccUXC91211ii3ZN5atfB1WwErUJsCGCpwWAErsIgowL+h4VvRjzrqqPlXxLep823ps2bN Sh588MHsS0EHDhw4v/60007L/kUN5mrw4MFlv3l9fuNWkPEKVSsYZF+iFbACVsAKWIFSBc48 88yEFSfYaKONklVXXTVbpYp2zz33XHL//fcn48ePT6ZMmZLo81XJq6/ytwnzgn+2vNVWW2X/ 0mb77bePYqdWwApYAStgBayAFVigAovMZ6i0GpW+9957GTNnzvzax55KP0NFJe0PO+yw+e1k uNIuXbqkBx10UFpXV5fq/wXOr2sJGY20P0O1wNvdDayAFbACVsAKWIGqCsgMJUsvvXRG5858 PVn1WGeddRLeGiTmzp2bHHDAAcmhhx6ajB07NunRo0cybNiw6h0s4rV+y28RH2BfnhWwAlbA CliBhijAZ6f0FQmJVp6SO+64I9FfAM7/nNQFF1yQTJ8+PRk+fHjSrl275NJLL03GjBmT/O1v f2vIoRaJfWyoFolh9EVYAStgBayAFWhcBQ488MBE31OVdO/ePdF3VCVbb711cswxx2Sfo2I1 6uKLL87qOepmm22W7LPPPone/stWrxr3TFpGb/P+/rFlnKvP0gpYAStgBazAt60ACxH8hTxf LtpV8OWgiwu+AHVpcYs+P6TE0dwVyL8CYned5/viI/GJ+FTMELPEF+JLUVN4haommdzIClgB K2AFrIAVsAKVFbChqqyNa6yAFbACVsAKWAErUJMCNlQ1yeRGVsAKWAErYAWsgBWorIANVWVt XGMFrIAVsAJWwApYgZoUsKGqSSY3sgJWwApYAStgBaxAZQVsqCpr4xorYAWsgBWwAlbACtSk gA1VTTK5kRWwAlbAClgBK2AFKitgQ1VZG9dYAStgBayAFbACVqAmBWyoapLJjayAFbACVsAK WAErUFkBG6rK2rjGClgBK2AFrIAVsAI1KWBDVZNMbmQFrIAVsAJWwApYgcoK2FBV1sY1VsAK WAErYAWsgBWoSQEbqppkciMrYAWsgBWwAlbAClRWwIaqsjausQJWwApYAStgBaxATQrYUNUk kxtZAStgBayAFbACVqCyAjZUlbVxjRWwAlbAClgBK2AFalLAhqommdzIClgBK2AFrIAVsAKV FbChqqyNa6yAFbACVsAKWAErUJMCNlQ1yeRGVsAKWAErYAWsgBWorIANVWVtXGMFrIAVsAJW wApYgZoUsKGqSSY3sgJWwApYAStgBaxAZQVsqCpr4xorYAWsgBWwAqUKpCqoxJeljb3d7BVg zCqNJ+U1hw1VzVK5oRWwAlbACliBrylQnIiZmG2oviZPi9iIcSuOZYNO3IaqQbJ5JytgBayA FWjlChQn4JiU57ZyTVri5TNmMX7FMa33tbSv9x7ewQpYAStgBayAFQgFmIyZlOELkbZRKHU0 fwUwUIxZjB9j2eCwoWqwdN7RClgBK2AFWrECTMaxssGEPCfnZ0p7iMVFN9FVdBYdBHOu3xmS CE0YjBGmifH5XMwQn4lPxMcixo0xjPFkbOsdNlT1lsw7WAErYAWsQCtXIN4aYgKOlSkm7VmC SbujaCcI2swWUWZDhSpNFzFGjAHMFBgqUsaKMWPsYqWK9jG+ytYeNlS1a+WWVsAKWAErYAVi siWNyRpTxWTN5MxEHWYqyjFTrFBR7rcDJUITBuPEOLASxRhhooqmijGjnDZQNFTsW3PYUNUs lRtaAStgBayAFZivQNFQMSFjlphTY14NM8XkjaGinNUpr1BJhCYMDBKwAsU4FU0Vb//FKlWY qjBUqqpfxMDXby+3tgJWwApYASvQehUomilWPjBJGKowS/H2H0YqzFTURxtVOZpAgTBUGNyi qYq3ZzG8mKnSz1LVa3WK67ChQgWHFbACVsAKWIH6KVBqquKtvFgNYcLmbb54qw8jBdFOWUcT KBDjxLhgqsI4kcbbfaRsF9/y02b9woaqfnq5tRWwAlbACliBmKQxR0zCYZIoZxviLUDSWJ2i XbRV1tEECjAmMV4xNvEB9OLKVJTFihb71CtsqOollxtbAStgBayAFcgmaIwRk29ETNqxQlU0 UrEyZUMVajVdGoaqOD5hrEhjZSrKYkxtqJpujHwkK2AFrIAVaMUKxIRbnIDJAwYKQ4WBKpop bXqFChGaMGKcSIHxIcVAkY80xi7aqap+4aXH+unl1lbAClgBK2AFQoHiilMYp0jDTNG22C72 ddq0ChSNUpiqosGijCi2m1dS408bqhqFcjMrYAWsgBWwAhUUKBqm0nzs4vk2lPh2UoxSROSL 5qmYj3b1Sj3A9ZLLja2AFbACVsAKLFCBcnNrubIFduQGjaZAmKhih+XKivXOWwErYAWsgBWw AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJW wApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAK WAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWswKKtwP8HsZcW LAoXYbEAAAAASUVORK5CYII= --------------050403010308000002090704 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example-4.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example-4.png" iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB5wURfr9ejawCywZ yVEUwYjxzKCY9UynnoqZv2c8w3lGTtd8euehYjoT5oQ5B5IJz0BUEMmKBIElbWDDbNf/ve6p nd5xNqeZ3e/b39vK1VWverrfVNV0i6gpA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPK gDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwo A8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKg DCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMJBkDTpK1V5urDCQMAxk9XReN 0c9QwoxIvTTEFK4MheqlJq1EGVAGWhQDqS2qt9pZZaB+GXC2rFA9Vb+UNm1tmb2MDmjTDoEe XRlIWgb0m1jSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEV VIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQ BpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEV VIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVgdozsOo3I1u2mNpX0AQli4uTq71NQJEeUhlQ BpqQARVUTUi+HloZqC4D515qJLNXFIN2N3LlGCPhsC8yCiCO2vQxctZF5UXHex8b+cNh0bhH xhvZ53Ajh58ksv2+IsefaeS3tdH0YHu22SN6PB6723ZGjjjFyK8r4+cPlq1vf856I312EjGm 8Y9d333R+pQBZaB5MqCCqnmOq/aqmTEwfbbIS4+LbFnhyKalvv+DSSJ3j/M7OvsHkTatRd78 QGT9hqjomDFHZFcIEdrET428/q7IOy+IzP7MkblfiqxYJfLUi3568P+adRROIivn+sfkced8 jnI4zuPPBnM2jv+7WSK77CjiOE7jHFCPogwoA8pADRlQQVVDwjS7MtDYDOTmGVmwOCqM0tMd 2X0XR0ZhlmnSp35rKJyOOFhkxyEiL74ebSGF2G47++Gb7xY5DHk6d/JFSWamI//8h8ghw6P5 rW8Gym09QKRjh6iA6dbVkT69RHr39HOtw6zReX81wtmyw04ysmhJVMi99IaRnQ/w08bcHo1/ 7R0jux1kZKvBRs7EbFp+gZ92x1gDoWZk1AVGHsYsWlGRkatuNLLDfkZOOc/IJ1Oj/bBtVFcZ UAaUgURiQAVVIo2GtkUZiMPAzO9FunQSiJmouGG2zAyR9FZ+AQqgYZiJOvd0kfGYgbI2kzNU EUHVq4fIvzCjRaHC2arCQiMHHeBgBqt8vSxLIcaZLe5bIlauNpgNM7Jxk8ifT/BrPxbH6t9X 5KMJvpC74G9+/CtvGrn132jHA5j9elDkoSdFvptl5IuvjdwxVuSZhxCeLPLjApHHnvHLfDBR 5L5HRXbeAcuQR4lcfLXI4mUi//2PSLetRB58Iioo/RL6XxlQBpQBZUAZUAaaBQMZPV1s6Wl4 G/uwa4457ffHuux611xxgx+/8wGu+fRL12zOdU3nQa75erprlq9wTbv+riku9vNs2uyacY+5 Zu/DXJPZyzW9d3DN86/+vl726ISzXMP+BcEys77387/7kWtOPjdadsYc1/TdyTXhsGv67Ii2 TIumPfSka5Ysc81Rf3bNxE+j8dfd6poL/uaakhLXtB/gmg8n+Wk//+rXkZfvh39a6LeDdTS0 sb/N4uTUTigDykCjM6AzVI1OuR5QGagZA8F9ULZkaamRDyeJnHGKSF6+kYVL/NmdrLaOnHSs P0vFclwCTEvzZ6DaZTlyyWhHpn3oyPyvRfb7A2erbI3lXc54vYu9VesW+vjxK8wUdRV5/lU/ 3z/vE/l0msjAXY2HP57mzyR9+Q1mzdJF9kfd1i48x5ENmNla+ovIQfvbWJHNuSKcNZuPY3Tt jOXIg/x2Poi9YqdjObNNaz/cCrNwHdqLDOj3+5m0aG3qUwaUAWWgaRlQQdW0/OvRlYEqGeDy G5fzgvbMyyLtshC/oyNcEuTSW/t2vuDgst+EtyB4sOncLvfxl36fTI1OvvTF8uEZJ/vLhsF6 6efy3uo1Invu6osaCpv+fR3Zdy+R1FQ/N4/5Ptow/38+fsCxpuCYCxeL9OgW3TzOXxB+Ns3I LOTv1iUaX1LiC8KzTxXxliUD/ZuFje8Ub9beeE+X+ywX6ioDykDiMqCCKnHHRlumDGDPkpEl y6KCirNRDz1p5HbsLXryfp8gzibZX/IxZo9hDmZz8Gu857CROyJUKLUmfebn539udH/0GcwE /SkaZ32sb9BAEc52BW31byLbIB7LbhBvmHH6mbNRjqxeK7LXoeJtnGf8GoQ3bDTCWbQLrxLZ lCvSGr9AXInyjKc9+bzICMxW9e7pC0L+gs9a2zYi87C/ysXq24pV3KSuG9ItN+oqA8pA4jIQ +b6ZuA3UlikDLZkBzt7QBu/J/8ab/TlwH5G3IUiGDvYFDwXQsIAgYU7OUl05JjpDdev1gl/V 4bEK7+MXdpgpKiwSGXmgyI1/Z+7yxqXC2PqYY9lywa/y/FmmG67kr/RE/v2AkZz1Inf8w58t 22agkbEPY6lxP38J8KhDRI45zMHynpH/POQ/+4p5uIw3fpx/XM5eXf3XaBv++n8ix54hMu0b EYqr3lgWtDNt0VzqUwaUAWUgsRgo/xU0sdqmrVEGEpoBbmDm85mSxfhkdD5+oVPH3/9isDZ9 WJuDpUHMOg0e5M9UBev4ZYXxhFAoFOWHM1Y8PvdD9egWjQ+Ws37OzK1d58+UNeazp/gA08KV gUbbBqmrDCgDykAVDFR+VauisCYrAy2ZgWQTVC15rKrbdxVU1WVK8ykDykAsA6HYCA0rA8qA MqAMKAPKgDKgDNSMARVUNeNLcysDyoAyoAwoA8qAMvA7BlRQ/Y4SjVAGlAFlQBlQBpQBZaBm DKigqhlfmlsZSEgGFi428v4n/iMJYhs4d77/8M3Y+LqG+a6+ad/GP2Zd69byyoAyoAwkGwMq qJJtxLS9ykAcBp59RfCuvDgJiOrbW2Ti6/HT6hL7wqN4+OewutSgZZUBZUAZaD4MqKBqPmOp PUkyBl56wwhneQbtbmTM7dGZni+/MTLyeD/+kmuMhMN+2s13GzwQ08jJ5/ozTufjWVB8yOYd Y4089qzIq2+JfP4/P/z4s0ZGXcCHYhq5H8KHTx+nLVhk5IhT8DyroUZOO9/Isl+MjHvMyD/u iB7/5+VGDv2TET5mYfFSI388Hc+uGmzw8E4js3/w8/FFx3wwaGqq4+W7coyRvjsZ2f8oI29/ 6Odh2+59xMiw4T6efzV6DL81/n8eJ155vrz5mpv9vvIVN+wLjfWOONbIC6/5x+Mxv5lhhHxs vZuRsy823kNB/dr1vzKgDCgDyoAyoAwkNAN8bEJt7eU3XDN0H9dMn+2az//nmo4DXfPtTNcs WOSabfdwzStvuoYvBd7tINc8+IR/nN0Pds2eh7jmy29c8+wr/guD+QLkX1e6ptPW/guJt2xx zX5HumaH/Vxz9zjXrPrNNSw39QvXrF7jmn47u+aZl1yzaIlrDjnBNXxB8SPjXTPy+Ghf+MLi 2+7xX6rMetiWdTmuuTrbNfsf5ee7817XXHqt7z/lPNeMvsw1S392za3/Rvv39OP/9YBrjj7V 79d7H/svQGZbY62i8nzxM4/Bdn88xTVZ/VyzbLnPEbm/6O/+S6D3OtTv/9Mv+i+IZhrz1cZY NqFPOm2cMqAMKAPKgDLQ3BioraAKh13TZ0dfANmb/kNPumbJMtece6lrXoLYsjbmdtdcfj0e IAqh1KaPa+b95KexDh4/Z70vZLpt58eXlPjC5cNJfpjl2vZ1zYaNrrnkGtf89bpo3Z9Oc83b H7pm4qeuGbK3H09RNGh31+Tlu2b8C6658Kpofgq+rQb7YYqgJ5/3hVr/XVzD9tAovCi2cvN8 wciwNR6D4jFoFHrxylNEUVgWFUXzU6h9MtU1FKPDhrvGdf20k86J9qu42DWte7tmbeC4weNV 5VdB1dw+pdofZUAZUAaUgYRnoLaCikJm692igsDe5CmoKAYoMAYM89FlG9f88z5/lme7P0TF xXzMXlGU0d54zzWH/sn3fz/PF0S2TooglqP46LuTa6Z9E63D5ln2i2s6YIaMdv6Vrnn0aT8/ BdCMOdH8kz9zzS4H+mGKHaZdBrF31Y3RPLbO/zzkmnb9o/1gfygIFy4un7ei8jfc5hrCGtvf c3vXzJ3vz6pRaFrjTN//vvPDs773Z+FsWk1dFVQJ/7HTBioDCcuAvssvYYdGG9ZcGViI16/0 6Oa/E499/G2tkZ8WimzcLDKwv8j0SdGeb87Dq1rwwuGnXhTZfZdoPN+3Z18ozHfh2Xfv8d1/ wRcl27RNqHsNXuXSq2e0Du51OvwgvoZG8CJjke9mGfl2hsiDd+GFxsjPlx933yqa/9V3RM4/ S2T9BiOr1uC9fIP9FyIfOjyaZ/psIx3xahke97LzRcb8zU8Lo/7CQr72pvzLGfgqmnjlZ6D8 kSOj9U75HO8u3NZ/f+HM7438Be2gbdps5JdfRXYa6od5XMuLH6P/lQFlQBloHAZ0U3rj8KxH UQbKGGgPgbRmrciGjQZCxsiFV0EY5Ipk4UXAfH9dwRb/3XhvfyhyyAkUXiIzIRSsaGJFFA5W OM2ZJzJkG7965gsKCq/cTiKt0gG8kJjCjfbMS0beeNc/Dt+3N7CfyOV4gfJNV/sbzdPSRIh5 P/n5lywzMhmi5uw/+8ceCjGVnu5I+yzUucjfKP7rSiPnXirSsQNeatwWguwX1uWLtUuvEW9z PGv7erqRRUv8rUoVlm8tMh9txQyTlJQYuQcvVv7bxX5b2Pdh6BNtNjbb812CmZm+UKMQC/Lk 59L/yoAyoAwoA8qAMpCwDNR2yY/7i/Y53DW9sIS16wjX/OMOf7mK+5AOO8nfp7Tj/v5G8cVL /TTmn/J5dJmLG8q51EfjMh2X83751TUj/uiaDyZG87Ec9x3Rbr7bX1LcY6RrjjzF32juJeDf iWe75sBjouUYf/2trsns5ZqDjnXN9vu6xu7L+veDrvkLjknjEiKXJZnOzeEfTfbjf/jRNb13 8DfHs23cYM79XbTBe7nmxdcrL89lUW60514pLumxLTQuT3Lpz9q9j2BD/OXR8AFHu+atD6Jh m6+6ri75JezHTRumDCQ8A+Xn3xO+udpAZSBxGODNd8uK2n+EfllhpHcPEc4QWcONH7M3Iikp XP6Lxtv0ityNm4x0aF91/pz1xpt5apdVdV4ea8UqI3n5IoMGsE3xyxQVGcnZINKze/l0PvZg IfrSs7tI507l04L9qKh8Xr7xlh0HYPasbZuKywfrqqtfX45cVwa1vDLQchlonKtUy+VXe96M GairoGrG1CRt11RQJe3QacOVgSZnQPdQNfkQaAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFl QBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaSnQEVVMk+gtp+ZUAZUAaUAWVAGWhyBlRQNfkQ aAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaS nQG8GEJNGVAGlIHkYYAP/FyxSmQlwFf28MGj+UBeAZAnZtNmpxjvQAyzR5mtJJSRISmZGSYV r94J8fU7fA3PVl1F+vUW6QsE36uYPCxoSxOcgXjPeIwXl+DdaFbN8993Vb5L8eLK56hBSAVV DcjSrMqAMtDwDKzN8Z+wvggvTl60TErxkuYteAFyeOVqCa3NkVZ4kbOTmSk5rdJkBR4sv8l1 ZXO41GwqKpYNeAHzBscxecBmMU6KcaSVuNKKbmoo1Co13W2TliIZGa1CA1zXDCwslh7FRdJ6 qy5mS5/eDl7hLHgToZoyUGMGKJasYIr128psug2r27gMBMWT9dON569Vy1RQ1Yo2LaQMKAN1 YYAvhV60VOSHH/lyZcf94UdT8OMCJ7xsucmEAApntpZfjDjzNm5yZ0qpWWlCZoVx3RXFhQUr ZGPHjXm1OHhxhWWWZ65wt+q38rdQP1cMXk+tpgxUm4GgeOIWGoata/2sLJiPYbXGZyAonlwc 3oatny7HycbXuIUsrKYMKAO1YEBfPVM90tasMzJnri+eZsyR/JmzJbx0ubRpnSE5aekyJzfX mV5YXDrfuGZBeMuWBZLbLqd6NWsuZaBJGbAiiS5FlAXexOn56do0mxdRXhxdtcZhgAKJZoWS FVCckabfuvTbNJsXUdU3naGqPleaUxlQBqpgYBnmlWb9IDJjjhP+6luTP2eepJUUS2lmhizE S5C/yd9ippe67pyS0Lof8hf2xK4nNWUgaRmwIolCiuLJYiP8TFNLfAYonLjMT1FF0CiqaFaI +aFq/FdBVQ2SNIsyoAyUZwD7j2TBYvHE0/RZTvFX30nB3PkmMxSSfGz8/j53s/tZcamZXlxY PEPWt16+oXxxDSkDyc6AFUxWTPFeSqQBjsHmPrXEZ8CBoZX4qYqUAHZM2XCKK4ZrNJAqqEid mjKgDFTIQHGxkXk/+eLpu1lS+L/vpAhiqnVGK8lJTZVZGza5nxnjTi+SLTNkZTvdg1Qhk5rQ jBjgzTa4xMd7KX4/6t2cm1E3W0RXMtBLK6YooCzs8l+1SVBBVW2qNKMy8HsGcvOMZLW1n8Xf pydbTM56f7/TbOx5+naWkzd9lnF/XSmt27aRFejldxs2mS9KxZ0RLtk4M/fnrnhogZoy0GIZ sKKKS32cmeJMB2/OasnFgB0zCim7j8ou+9WoJyqoakSXZlYGogx062qe7LWDc/rO25vC449y so4YaUJDtk0OccVnOf24QGQ+MG+BUzJjjimYMVvSC4sk1C5L5hcVOl/l55V+W5rizipZ+fPc fNmmKNpz9SkDLZ6BWDFFQcUZqswWz0zyEcAxo4DiMl9QUNVYVCXH1T/5Bkhb3FIY6LmydavS rQ7Kap9ynHHljxkZpvUxhzkhiKvMwYNEtu6PjRWpTfMxKykxguc3ybLlIj8DeERB8awfnIKf Fpk0PBAzPauN87Mj5ocNm813Jmy+d0Kh+11TclTx6laYn1JTBpSBShiws1IUUZzhaB1BW7hf 6x4qsJAE5m+hkr3QVD6JhT+SIQoBPmWF+6rsRnV4q7amudJX3S7NoQwkJQPpPYqGpDipR3Xo 6BwVLpHtCgqkS6+eUrDjEEd22VHaDh1sQttuLVgmxE9L2otgNkgiH+pq95cbwnOwyztnvcg6 Ag8ZoH/1GnEx61SwcImEf13ppG7caDLbtJb1eDTBL3ju008bN8pMbA/40TEl8wp/y1iGI0c3 XHbN656R1npe4Uqnc7n4ardKMyoDLYYB3jetoOIyH2c4KKjwafaAPYXRjxbi1BKUgci19wA0 j9sXCAqqLQBn5K2gqvZgqqACa2rKQMMxsLBVWtd+Q5y00NBWqc6O2G+1J57sPSBcKll4snfb khJp1TpTirBHqaR9O3EhsNziEnHCeHFKaakjJWHj0IUgcqCjZPNmSS/YIun4JV1Beppswqbw 9fgQr8GTwlfn54eWhEtKl0I0AeFlhavfwbzUydX6hpXePXwyZqhOL1oZOrbhuNCalYFmwQDv m9wuw2U+OzvVBn4KKv4E/xMVVGAhCSwiqA5BU/moCwqqfMDOUlFQ8RVW1RZUuocKbKkpAw3H wDZFJWtlFuqfxTlkfmLLW3aosN0VHfJzW3VctTbUEe9KaRuGfsJf2AmZMH5HFHZKI27YhIvS ijfIyv+s3yLZNV7fL3/c8iFHnP3FNZ+Xj9WQMqAMVMIAhVXwl34UWIRacjFgx42zjnY8azXZ pIIquQZeW9vsGIAw2py9vmizYNHOn2Nuii46xn2jsDAfS4JqyoAyUEMGeBPmzZjQe2oNyUuA 7BwzO34cy1qbDn6tqdOCykDzYaDwt7TJzac32hNloFEY4CyGhZ3Z4I1ZLbkY4JjZ8bPjWasZ qjqpseTiTFurDCgDyoAyoAzUKwPBG7C9KdfrAbSyBmfAjltwLGt1UBVUtaJNCykDzYeBVt3C R7fqUXJY8+mR9kQZaFAGgjfeWL/eUxuU+gapnGMWO47BcLUPqoNfbao0ozLQPBlwUkLX4wEK 3DOvpgwoA8qAMlBLBnQPVS2J02LKQPNgYGkGfhO8S9Hq1f9rHv3RXigDyoAy0DQMqKBqGt71 qMpAQjCQ0b33H9CQ2SJ9+DA7NWVAGVAGlIFaMqBLfrUkTospA82BAVdC+xvR5081h7HUPigD ykDTMqAzVE3Lvx5dGWhSBooL8h6UzWv4dGA1ZUAZUAaUgTowoIKqDuRpUWUg6RnY3N57oGjS 90M7oAwoA8pAEzOgS35NPAB6eGVAGVAGlAFlQBlIfgZUUCX/GGoPlIFaMZDeM3xqq+6lf6tV YS2kDCgDyoAyUI4BFVTl6NCAMtByGHBM6BRjzK8tp8faU2VAGVAGGo4BFVQNx63WrAwkNAOO IwcUlxZ9ltCN1MYpA8qAMpAkDKigSpKB0mYqA/XJQHr3oqHGyAZZ12ZVfdardSkDyoAy0FIZ UEHVUkde+92yGXBSholj3mjZJGjvlYHmycCoUaMkPT1d2rZtK23atJFevXrJ5ZdfLps2barX Dt9///3iYKr7888/r9d6k7UyFVTJOnLabmWgDgwUr0p9vmhlylV1qEKLKgPKQAIzcNVVV0le Xp7k5+fL3Llz5f3335fx48fXa4ufe+452XPPPeXFF1+s13qTtTIVVMk6ctpuZUAZUAaUAWWg Ggx06NBBTj31VJkyZYqXe+XKlV6YM1eHHnqoTJo0yYufM2eOnHPOOXLXXXfJwIEDZbfddpPZ s/Fmqjj2008/yYoVK2Ts2LEyYcIECYfDZbmOOOIIeeaZZ2SvvfbyBNfUqVPloosukt69e8sJ J5wgBQUFZXmbk0cFVXMaTe2LMqAMKAPKgDIQwwBF0csvvywUOrQHHnhAevToITNmzJAzzzxT LrnkEsEvfr3ZLM46UXB9+OGH0q9fPxkzZkxMbX7w+eefl5NPPln23ntvyczMlIkTJ5bl+/77 7+XRRx+Ve++9V4YNGyYjR4708rz77rtCIca2qCkDyoAykPQMpPUIn5HR030l6TuiHVAGmoYB TkSkA1lAN2BrYBgwAvgTAG3StHb66acbtsMiFAqZQw45xGzcuNFr2BdffGFyc3ON67pm5syZ Xr7NmzebadOmmc6dOxvMNnn5vvzyS7PNNtvE7cyAAQPM119/7aVddtllBsKsLB9mvgwEmRfG /iqD/Vze8RiBvVzm2muvLcvblJ4IPxwzjh3HkGPJMeXYcoxrNOmkr54BY2rKQEtiICSOvhC5 JQ249rVFMsBN6HZ2iRvTMzIyynjg8txxxx0nEFOyww47lMXT061bN0lJSfHiuKl9y5Yt5dIZ gNCSpUuXygUXXOBtSs/JyZENGzZIYWFh2XG4vEfj5vi+fft6G+QZTk1NlZKSEnqbnamganZD qh1SBqpiwNnfLQk/VFUuTVcGlIHkZYDLcJht+l0HSktL5bTTTpM777xTPv74YykuLvaW42xG zGZZb4UulwXPPvtsGT16dFkezIp5G9+5R4pWnXrKCjcTjwqqZjKQ2g1loFoMdM/tKo70KFl7 x5xq5ddMyoAy0KwY4EwSZ5SOPvpoT/Q8++yzNeofBdgrr7zi7bHaY489ysoef/zx3q/9rKAq S2hBnqqlaAsiQ7uqDDR3BtKk1QAj5k6RbLe591X7pwwoA79noEuXLt7sEjeLE7NmzRIKIz5m oTr2wQcfSPv27b0ywfwUVO+9955gb1YwukX5nRbVW+2sMqAMKAPKgDJQNwY4EcHVnVZAa6At 0A7oAHCNbQI2WsNJbFu1apX30M927doJlwGxYT3uEmFi96JureNDSWEnATnARmAzkAfwuQ5F AJ8FUe0vn7rkB7bUlAFlQBlQBpSBlsQAH5tgjZvQ4+23sunqVo8BXfKrHk+aSxloBgxkh9K6 F++JX1PrzHTjjib3q50WOeRUuD8DnNmwxpkOTml0AW4HPgVi7QVEPBeJtPVdjXBxBKVwCRu+ Cf4/At5P4mPc3/9sCxnUlAFloG4MqKCqG39aWhlIGgZa9bjhkBQn9W7BS/ySptHNs6FcHrqh gq7xHR77AVsF0vk8nKMAiqqgYSy9Z+Uw/UFgfCB8M/y0uQAFdBCZTFBTBpSB+mVABVX98qm1 KQMJy4Ajof0xYfF5wjaw5TSMQuhCYJs4Xf4BcfOA4wJpB8PPB/d8EohTrzKgDCQYAyqoEmxA tDnKQMMx4BxgHPezhqtfa64mA8uR79/AuArycybqxEDaCfC/CtTmaYjtUe7PMdgNYbUWzsCo UaO8h27y4Z188Cff68eHgW7atMlj5g9/+IP3ME7ureLG9Z49e3q/BOQGdj7sc/DgwYInpJdj 8bDDDvPeEVgusgUFVFC1oMHWrrZkBuamY+fU7kWlOdNaMgsJ1Pd70JZBwPFx2vQS4kYAHYEU 4FiAS4G1MdZxfgz2rU1FWqb5McBHJeTl5Xnv8Js7d673YM7x47ly7NsjjzziPbMKr6URPi5h 3Lhx3jv7+NBQvvz44YcfFr74mMZ39/Edfg8+yNXnlmkqqFrmuGuvWxoDXfp3MeKeJ791z29p XU/Q/vIn2fx6PxYIblBnc5cC04FjAAqywJgAACAASURBVO6nYt7aziwuQ9mDYnA/wmrKQDkG OnTo4M0uTZkypVy8DQwZMkT4DKvIowZkr732kr///e9yzjnnyA8//ODNXj3++OPSqVMnW6TF ufrYhBY35NrhFsnAujYr8fOv2s5ytEjKGqHT7+EY3Et1fZxjcay47Edx9TJgADVloMEYmD17 trz88svesp89CF5sLHzvX1FRkTczxffzjRjByVPfbrrpJu9hnhRXfJ3NkUceaZNapKszVC1y 2LXTyoAykCAMXI52XBCnLa8gjpvRTwLqIoS5ZMgpg1jwV39qLZwBvs+PM07Errvu6r3E+NRT Ty1jZc6cOfLRRx/J5MmTvZch8+GfixcvLkvni49HjhwpBQUFctRR/CFqyzYVVC17/LX3LYSB Vt1LL8JkR/R18y2k30nQzUVoY7wluNWI/x/ApzZz+a+2th0K5sRBVm0r1HLNhwFuQl+3bp2H /Px872XJfK2MtYsvvth7Px9nrr777jtvBuqBBx6wyd6eqYceekj+7//+T6644gpPWJUltkCP CqoWOOja5ZbFQFrP4mH4CnqJyIDCltXzhOntTmgJf7lHGw7YB3QyTLsB4IzROgYCNhL+wYGw 9Qbrs3F/hWe0DUTct+Gy3njYHJNXgy2QAW4u56/4iIyMqr9vDR06VLg0SOOv/c477zy56KKL vM3pFGI33nhjC2Qx2mUVVFEu1KcMNEsGQiblAGzB+axZdk47pQwoAw3GAPdOcTmPs1dvvPGG jB07tmyf1L333itr1qyRm2++WfjqGs5U3X///TJjxowGa0+iV6yCKjFGiN9Cuek0Dega8T8M N2ijEJgciVgAFzMO5YxfL3KBPwLB+r5G2L6Ogsfgs2xseAf4+W2Z8bF4BnFqzYIBZ3+jD/Rs FiOpnVAGGpOB0aNHe8+o4rOq+MypQw45RK688kpvHxVno7j8x2dY0fbZZx8544wzvOU/zl61 RNONiYkx6hRA84F0gG8sXwNw38NhgN0/QUF1LnAQcDOAp157fjieHYP/TwPdgQGArS/4MMBV iD8L+BiwRkG1EGCdas2QgYwe7prCosLdZH1rPlBSTRlQBurGACciUoFWQGugLdAO4LW7MzDB GH4/VUt0BiKPgOAPP3i/3QhwKZz7FgsAPq4kDLhAtYwnhlpiMnALmvUg4MRp3ouIwzKON5tl k0+A53WAs081Nf3015SxpMm/NKPUCR+uYippBqyhGsova0OAvoBe9xuKZa23RTNAla2WmAw8 hmZxNukc4MmYJnL26XuAT1B+HOA4cobqFKA2tiMK/Tmm4CSE18bEaTDpGBhQWLJSmnpTw6+g 7QiA52x92n9R2UOAv0vWnzF4IuYATJ8GcDbhCuBAYDFwJ7ACoG0LXAzw3XpTgHsAfitlmYrq 4xea84Gg8fNaCvwd2DmQMB1+PsCTxs/saQDrHw8EZ4sR9NK47H8fAxGrqH1Mrqq+nZCHX874 jXsJ0BvYG3gJuAPgt3A1ZUAZqAcGVFDVA4kNVAUvzNwn9SbwRpxjcJaKs1IUVLy4c2aKN4Pa 2G4oxKnqoP2IgAqqICPqry0D+6Dg6toWjlOOXx6I/wNeCKQPhJ/7AscE4n6O+P8Fd3fgWoDn Oz8r2wMUTW8DE4EbAC59U9BcDVRW33Ckc4ngQ8AaRRKNwuo2gEsHNNv3A+F/BOBxKOqeA/gl aBowFDgeoOij2LHG5aSK2ldZfSzP51jhcRkeT/lwdwZmAh0Blr0XuBBQUwaUAWWg2TAwGD0x QHBTenqkd0/DfRAYBUyOxNHpCxQC7QE+GIQXR2vB+mwc3VXAocEI+HlRvzEmToPNhAE8f2qc dC7o1UjdOQDH+QCgEH8F6ADQ3gS2BvYDeJ5yBoj7uXg+9wesvQ/PdjYQccfB5TketOsRGAts BigMrB0ND2d2Yy0FEfzC0SeQsAb+Q4ATgf8F4llfDsBlsYrqY/ZngNjPEuMdgJ+zePYyIv8W SODn1rb3SPjZp+8AxlurrH2V1ccvy98AHIPOAOu9BLgT4JcltnMqkAHQeA24COAYrAQ4TqyD 1hN4EVgBfAxQqNE4+zUeuAZYAkwHdgYqspuRMB+YBXAMrfGcORP4GmCbhwMPAb8C3MbQGog1 juldwBqAZc4GaBy32wD2ge2luGZfabU5jl+y/H8eIx3IAroBWwPDgBHAnwBsoVJLBgY4VpEx 49hxDDmWHFOOLceYY11tq1HmateqGeuTgWtQ2anArjGV/oLwt8AfgeMAXvDUlIEoAxBSTsg5 VXJa88bSGDYOB/k3sCfAa8vFAG13gDfFTsClwEaA4moBwJufNX5BcG0g4vIGlRkTdwfCnMlZ HxM/CGFeED8HeJO1x+8Lfx6wHLC2CJ5tAZbhDd4aZ47Yzi5ARfUxL49DEcCyHwJ7ALQeQBh4 FfgeeATgjBCNZWKPtY2X4gsZ9mlKJGydytpXWX3s208Auf4z8DbwAPArQOHCGwn5Y19pzE9e KVIOAQ4FjgRoFGIUibsCzwCshyKlDTAKoOA6HPgZuA2IZ7xZHQGcAJwCXARY8bUj/OcDlwMz gYnAFuBoYDDA/LHGseUx9wVuBCjAyBXrPQzYCzgIOB04C6DV5jh+Sf2vDFSDgdRq5NEsTcvA ahyeF6l/Al/ENIUi6iaA+yB4kayttUZBe2G1dZTAk2sD6iYfA+mt0g/Aj40+a6SWp+E4WwG8 AfKY5wLtgFiz5zNv6H8DlgIhgEKKN9u62AAUTgd4g90OuBXgZ4MiaRMQtF8RoCDoD2wGrFF8 sm1Mq6i+x5E2EPgK+C9AwTIJGAr0B9oCbwIbgDHASwBv8v2BYDuWI8y8lVl/JFbUPqZVVN8g pC0DaCcB5JpGsfsB4AD8Fr4SsPY0PJ9GArzeHAW8DbwHzAbygR8AcmvbzeNfCZQC/waeAmhD gAzP55dhvtOARUAngDzvBrBeGseKfKYAZwO8ruUBHwPbArHG8+tuYGEEF8Dl2I8G7gPILe1B 4FTgKYBW5XGy2+CX0iGZBIJ4Hrj4Z8AWz0+3LA7PIfESwSPcEDI5Oa7M+W+BxxWPo9YCGUht gX1Oxi6PQ6N5ocDnuZxNQIgXD36rrItdg8JE0D5C4PBghPqTiwG8oWt/3As+b6RWU4CfD/wH 4Pn4KnALEGu8ofJeROMNmjcq3qDnAdbOgccKgC7wTwXCwPvA1UBFdhkS+Blh/ZMBih7exK8H OgNB45cICq1uQDAtE2H2hTfkiup7HGk9AduPL+Cn+Dga4IwUBYNNWwv/1wCPUQCwP9bawEM+ KjOWqah9ldX3K8odF6mYwo7H7Q3sBzwAXAd8CgSN4sTaUngs17xPUCAOA34AgvYbAhRTtDyA /NFeASgwaX2ALQCF7gnARsCKLXg9Y3tpxcAvAOuihYE0z1f+X38EfwxEPRPxM558W1sCT1cb gFvlcbLzZXV2FtroyD4sF3vR9eIQyfgQA7DNrrzzdIE8D28HL0L/tUgG+EFRa3oGfkIT7OeW F2Drty3jBd5enGwcXeaNd7EJ1hfM3yMYiPhHwSXUmhsDxtnflfCTjdQtzg5MA7YBdgIoYm4H TgOCxlkRa1vBQ0Gz2kZE3E/gUuzQ3gB4888B1gCV2XAkcsaDAoJGUdAP4A2ax6XQ4TIXbQAw F+gF7AJY6w/PAoA38uFAvPraI343gKKNRvG0DGAbKQ55n50H0JYBFD4UFGwH22OtPzw2n42L dX9GREXtq6w+Cp8dAc4S3gZwLBYB5wGctfkf8DcgaOTIGstSLKUALwAcg0MBjjP7Ys21nhiX 5YM2DoGOAM+PzcA7QNAqqieYJ+ifj0DwenYIwozjmPYGLK+D4efMl7XqHudpFPAElS1Ykbux FA8Qz5dnka5iqiKSWkg8P/hqyoAy0AwZKFoV2rFkVfp3jdQ13rhnAhQbc4CXAQqYWNseEQTt DICzDFbknAp/Z4CzCJ9FUAyXN0SGecOszE5C4n2RDF3g8ovCa8BK4FvgXIB2MsB0Cgze2Hnj 3BZoDVwLTANoFdVHQcEbKGekaHsAuwEfAN2BSQB5oBi5BPgIoKh6Ezgb4HWXwoLts8eCN65V 1r7K6iNvdwNPAUuAwwG2ZSqwFzADoJgM2gkI8Et2W+BE4AuAIqgz8C5AMcIxq41RaFIoU0xR zO4LOEBNbG9k3j1SgLycBrQCKKwogDYCbCfbmAGwfo4Rj1szy8UMm8FsGZb2KixopCgnLBdC TD1YYR5NaFEM8MOjpgwoA8pAXRlYhwreA1YCXHKhYLkciLVliHgFoNjgTe90wNoL8PCmmWMj aujeg/wUUJxVGgR8CvDGSzsbmAxcBFDoUTCEgaXA1cB0IA9YDQwHaBXVR7FyHXA/cDswBGAd LD8VmAhQXLKPFE/HATTmPxhYDnQAHgaYtzKrrH1V1TcBFa8F3gQoqhYAvYH+wIcA2xE0tp95 MoF5wF0AheBTAPtD4TsNoDj9N/AUUF17ABkfAUYDpcAzwA0Ax6u6djEybgK+A8YDFLDsF8fx TiAXeBb4GFgEsD90PwKqbTe2wab8kHfupkGSUZTFs/XrXDl1XIF3rrWNl0HjWh4DFZ0sLY8J 7bEyoAzUBwP9UQlvyD/GqeyPiKPIGgn0BygWDFDf1hcVFgJrYipOQXgbgDdZ3oSDloVAV4A3 6FirqD470/QLCmyJKcT6tgLYRzcmjfXx5r8hJr6yYFXtq6o+isiBAPtnZwSDx3sOgS8BCh3O rlEYB42zQPnAZoA8UhDmADUxnhfkmHzRyE/sGHkJNfjXB3nZVoo0a3ac2dbYftg85dzzsXWi V5Y3Y/g3SKjtvUTMQMHPGTDfOFsFgYUTdhE2oB87Ls8TpK2RSEHVDiAnnQF99QxISAar71fP pCZDp7WNdWKAFxx+4Hlh501GrQUw0KqH+6brhu8s+S3960bu7rJqHI8Cgzf2hjJ7w46tnzfd +bGRkTAFCRHPKqqP/fgpXgHE1aa+CqryoutaH0VUPCEVe0yKJiLWVgUiyGNNxRSLU3QGuayr mGKdy/kvxiob53JZs7nM205GY2bhKiTwWkmJvwL/H8w18gQunN87DoRfREzB/RIDcRzEFMVa VGyxnFqLZ6AhBdVYsMsp13/UM8unoT5+y7F7JVj934Gd6YnYdLg8Pu1YgGV48RsPcDqYxg/D FcCBwGLgToAfJFpF9bHME16O6L+H4J0GHADgi045OwuhUmBbgNPV/HY8BbgHYHus9YLnfuBE GwG3svZVVR+/Ld0OsF5ewEqAg4FlAPvG/jaEHYlKlwHz4lTeEOfD3jgOx5T7M9QsAz1X8lvz oSW//XyKjUoQl+Lj6QRpizajPAOvIxgUO+VTm1kom18ys+QSCKkr0TXeT/gchB8gnv5pcuVl pHszmNlt8Xw/B7/29GemXszJlXPG+dfThrx3sjlqSchAQ54Ut4IPU4+cDEVdxwMUQS/F1Evh chtAAUfjPgjagQDX7blWTxHxHMCbDAXQv4DdgWuB3YApAKd6KT4qqm8g0nYAxgDWfo54hsPd CHwYCdOhaOLs0NvARIDtuBngB/hqIAsYBZwBDAKCVlH7KLQqqo/leby3gOuBr4BdgVUAx6MP 8ARwHMC21reNRoXvAvEEVX2fD2z7DGAkPS3dWnUL/xEnW5eS31KfzCjtujf2gICbbYoSjBcK KkIt8RigoGr2lo0ZKSdLLjWYkYJ46uJ12MjXCN+Rnevtt4M3YC6WQENyGSJvz97sTQ4wPRTI oV5loF4Z4En5X4A3bc4M7QXQ/grwBkubClA4zAIWAMGZGN74/w8IGgXGIcEI+Dn7wVmO74AH AGv4klHjVz2koEwxQIFhbQ08PGZl9R2N9MdsgRj3GYQPjYljkH39XyD+QPhzAH4oewLs04sA j2+tsvZVVh/L3wNQeNIeBjiDdjfwPrA/cBlwKmDtKHi4DLIcuB/gPgfaTsCnAOOfAtoBtCuB i4AJwArgZSADuBTYACwDjgUuieB5uBSgwfOhF8IfAeuB14GdgbMAil9rHeD5BmgP9AAo1DYB PIeGA7QdgBc8n7+v4y74ySPLnQ1YOx8eijyC7Yhn5DxeeY7TbcBKgP1lX3iO0D4AzgS+BnjM 4QD5/hVgv1oDjWKtuoePyujpmrTuxXtm9CzNzuhReicPzHCjNEAPogwkMAO4OLW6uZ1cdnOW rIZrCDxr6nNsQD+4qmYjH6/7QeM1IR3IAroBWwPDgBHAn4BkeOuKthEMcKwiY8ax4xhyLDmm HFuOMce62lajzBXUegHiC4CdgCeBRwHaAKCf5/N/uXM2/DzZOEvzOMDG0ihsSjxf9N8e8G4X DXq+9/H/CmBKTDxvtmHgVeB7gDfljgCN5PAGbG0xPNsAfYE8YDlgbRE82wKV1TcI6azzc4A3 0IsBa4znzZXH4ywV+0Bjmdg2dEJcF2AlwD79BwhaZe2rrD7WcSDwFtAd2Bu4CPg3sA/wFbAG 2AqgcXwoiP4OHAqwzRQc7YBJAOuhCOMYPQPQ+gB3AC8BpwK8YZ8EUDiRE/I/GaBougVYB/AY wfOB4fkAhdRC4AmAouRsoA1Ao9DjebUJYH6ObX/gNuA1gP3jSc8ZOBrH4nBgX+BG4CGAXFHc XQeQ51OAC4HTgVirqDz5OwzYCzgIYNmzANqOwPnA5cBMYCKwBeAFeDDA4zWOhcOLDD5HoVDq c3C7hkvdKendS19MCaV+ndG9hBcLNWWgxTGAC1MKRNR5Xdp515l78VWoG26hX5tSOQQzUvvf ku9d5yrlBfnerTSDJioDEQZS64GJXqiDNzfag8AUz/f7fzchiqKFoPA4AOANiDf7uthAFG4L vAlsAMYAvNnzJtgf4A3Z2nJ4mLc/EIxH0JtV4M28svoGID0d4A2bgu9WoAh4HGA5Cpb/An8G KEiGAv2BzYA1znLgnlcmHGx80O2PQEXtY1pl9aUh3QU4k/URQKPomQyEAfI+FqCNAiYC7zAA uxToD5wMLAGs0Lse/pUA+aG9AlDU0Mg7uXgWyAfWALkA7VvgMs8X/bctvHsDI4FCIBuguP0p gkPgss7jgReBbQCKJIoU9vtVgO08CpgHWDsXnruBhRFcAJdjdTHA89JycR/87N/zQNAqKj8a mViG5w6NdZ0KPAXQeA5w3FOAswGe5+zPxwD72ihWtG7Vz6169AvhYD3xvWtdSkoKeUqB//Wi 1WkVfSYbpW16EGWgKRjIbit/wrLebeJ4X2541Z2NC+8YFUhNMRot45j1IahuA1XjgVXAF8C/ gOCNDkHPeKOztgwe3iR5M7fWCx570+sBfxHwF4AiYBegIuMxOwH4rHi2Fv8529EZKAA4E2St DTyLAM4iMD1orRFYDFRWH8WBA/BYFCgUUacBjwM9AdsG1nEUQBHANgSPlYlwCWBv0PD+zipr Xzfkrqw+N1IbxeUwgDdZCoifgAOBQcACgNYf+JGeiH0Hl/gnwNkXiiNrrMcel+LKGkUUuYtn 0+NE9kfcUoBiisa+UpTQOBN1DPAhcDDA8d8NmA8ERSTF3lbAPMBaf3iCfXkmksD+7gFcHQmn wWV9sdYfEfHKM57nkzUeu6sNwP014i+G+wtAMUXjectjNZINAJ9uPm4g7cRxrsVJmo6zcW1h Sc7ZjdQAPYwykBAMcBkvJcX7kRE/97wqL8QXixuz87zri71GJ0RbtRHNiwHeJOtqpajgcICC 4jWAN7K2QKxxGckab9arbSDi5sC9KIKpcCdE/JfCrcy2Q+KQQIZl8BcAvFHzBtcPsNYfHt6E GZ8FUIhZGwDPXKCy+oYjvQNgjcKA7W4PjLCRcPmhXQYw7WegP2CtPzwUNLzhVmSVta+q+r5E pRRzbwMO8AbAmaZdgeuBCwFrFBAUr9a2gWd/YBPwMbBVAH3htyLQijZE1dgoZlhvSqQkRceo iP8VuGz7YcA0gPxxTNjGEGBtMDxf2UDEZb3BvhyCcB+AfbkEsH1hHh4j1ioqz+P3DmSOPXZd uAhUWy9eT+hi0NNxAykQU3qKrOuaWy81ayXKQIIzkN1ads9uJ59ATE1EU/fAZ2Al5uovwK/2 hkJMvYQ4FVMJPobJ3rzgTaq2fXkaBY8E1gDjAQqFDCDWTo5E8IbEbw72hsiZKs6k4Bt22esm VsC/KBL+HG5l1h2JkwCKGt6kefP8CCgAuHR0NsB+UiyMAnij5o3nW+BcgMa2cSaLx6ysvpOQ fh9AY37W9xpA8fYscDRAY/84s/IB8A6wD7At0Bq4FmAbKrPK2ldVfbeg4hsBiszzgGOBWcBh wDXAjoC1d+E5GOgHpADsWzdgCjACoIiinQZMBaq6IFFcZwKV2S9IXAr8KZLpLLjHRPzknzM+ NwMvRuJ4LiwDToyEKZI4lrEckhe2sxVA0cTzciMwGTgF4DlJjAf+BtD2Bnb3fP44xStPjs4A WNYBOMafAIloS9go3Ei24P8LhbrUl4hjpG2qZways2Q77JN61UmVb/EBHYmL1EZ8Bq7blCuD bsqT/2ZX/uW1nluj1bVkBlLrofP3o44JwGwgC3gUWAfE2v6I+B7gDfGfwByAdjnAm+xMBmph U1FmIsDyFAUh4DiAxrZRMCwHOgAPA8xLOxvgzfYioBPAG3YYmApUVN89SHsNYF+5lPQpwBt5 MXAdwOPdDlDMXA3kRUD/9Ih/NdzhQFV2NjLEax/FSGX1UdgeA/wXYH9+BDjOWwObgTGAtQXw UDDMB1YBc4A3gFJgHLAQWAy0AUYBVRmFBseWfazM2IYXAHKVD1BUWXsZnpuBN20E3NuAZ4Hr gZ7ALQA5DxqF0gcARQX7fSdA/nkMjhF547nBsbsg4r8Y7iZgBvAU8D5gy7MfbNtzwEfAIoD1 0f0YYF00iiz66dJsvB/6fdjG179rSn80knIEGrKpMDz/ijhtqf9j1qxGEyd7vLg42TRKGSjP wA0Z0i8tTW7E+X4WPn0pOJEwKyv3F+bK3fjwbiifW0PKQMMzYG8CdT1SR1TQH5gHFAGxxrhe QDrAGxhvVPVtWahwK4A3Tjem8r4I5wKxH7IUxG0D8CbJm3DQqqqvEJkpXoLGmynr+wXALEE5 Y31dAd6wq2tVta+q+jhbsx1AIbUMqOjm1QlpFFEcm6B1QYDjRlEWK2CC+YL+tgiw76yvMuO5 wPpXVpYpkEZRR1FI/ihsYo3nMtEboDi0fbXnOMvST4FYmbE82xQ8h+y4kkfWnZDWqkfBxY6T 8Z+wmzMivLrrtARspB0TNs366cbzJ2DztUmJwACW9nriK+INOGtGY88g9wqWGEeeKA7LLXcU NMrnk9cRfknl9ZWrDrzmcUsLv7TzWvqa/4t8+NQSmoHIq2dORCPXAxsBXuN5fykAqFuoC+z1 Cd7Kzd5sKs9V91QrqOLNXNW9dq2hJTPAc9iexxQ+9FvX+slPMB/Dzc7SOnw6yKR2ah9et+P0 BO1cUDxRsNqw9VsRa+MTtBvarKZg4Po20i095M3OXwQhlYFlPZ4vL4SLJfu2oiq/KNVnk3kt sYKKWxysoGoPPwXVGyqowEISWERQHY+mUlBxQsEKKk4K1FhQ8aRoDLsNB6HiU1MG6pMBK5Ks cKKQIjizZ12bZvPy+PQ3OyvZeCBn1gh+a04ks9/wrFCyAoqzmPRbl+NiRRXbb8vRr9ZCGfBm pCCkIKLOxyc3E2cFz4sJYSM33ZZX7pe5jc2QPZ/p8ry153Jjt0OPVzcG7PWH4xcc0xrX2liC 6tYat0wLKANVM2BFkhVPFFIEp26bpWiqmpKky8ELGJdKeFEjaFZUMU2thTKQnSH9saB3FW5x 53FGyhNSRt4Iu3LzrfneXshEYcYKKZ6/3hIRZj70+pMoo1N5O3iN4ZjZ64+99lReqoLUxhJU FRxeo5WBWjNgL1hWTPFcJtIAR6fca81roxaM3Hi4F6WE4xY4OC9wDKuoCpDSErzZbfDcwRTM SBnv19f8gsRzYAKE1K0QUt8nEAdsF2/AVlDxHCZOAbj8x31V3PvJGeMMgNcmXqN4zVJrPAY4 PhRNHBvufeZqGfdxc3mPy3x23HjNseNZq+uOCiowqJaUDPBmywtTUFClI8ybs1pyMcCbjRVT vJBZ8OJWqwtbcnVfW5tNodFWjsO8zkU4E0ZEGCnBPqnncQbchaebz0swloLnqJ2Z4k2b+254 0+a1iGKQxvOYP+qxcSqoyErjGfnnGHEMCO6PoqCiy7Gye6XsTJW97tT42qOCCmyqJS0DVlTx wsVvfxRTvDmrJRcDdsx4AePFzCK5eqGtrTED2Zn4VW6anI/ZqNEQUj1YAU6CPPx7DHMK/8ne UvYmghrX3YAFrJiy5ytv1vaGzZszb9RWTNl4iileoxhvvzzAq9YIDHCcOA6ciaKgoogKiiqO GePtOAYFFctW21RQVZsqzZhgDMSKKV6seNGq6sGiCdYNbU5kzHgR4wXNiinrKkHNjwEHy3qH YG75QnyIj0H3UjyJYfBWBINnBebJs9n+ckyi9zwoqHhDpljiPdXeV62Y4s2b1ybG21l1eNUa iQF7LeEMFMcpKKq4/GdnqayoYv4aCSnk98wOvA2rqwwkEwNBUcULls5QJdPoRdvKGSo73U6X Nx39Fh/lp1n4stvKDhjVUVjWOw0d6sNOYUmPN7EJkNEPZ+d5b8pgdDJYUExx5sNuPbDLeTyP OfPB65IVUxRcKqhAQiObFVQUuEFRxfGxs1U8D2P3UtVYVKmgauSR1cPVCwO82VrYCxkvVlZU 1ctBtJJGY4BCmBc0XuDsTceOL90aX9hQRi0BGBiTJYPTjPwJD948GUJqp0CTlnrLekaewP6o 2AckB7IltDdWVPFcpfEGbgUVZ87tUp8VUzYf86o1PAN2nDguFFVWONG1y310GWa6zlCBBLWW xYC94VpBxS8HBG/OasnFAMeMyyIcv1hBlVw90dY6eG7UbhjJoyGYToSI4qyU9+0HdzU+PPGV UiPP3ZrrvYszmYWyvUnzOsSb4tzUFAAAIABJREFUsBVJjGeY4Llsz2k9r0FGExnHxI6XHRsK XvqDM1M2zs5osUyNjIOtpgwkKwO8iNlvfbxg2W+DydqfltpuO272psMxtTeolspJ0vQ7m08K z5KRaPDRGLQjMXI9vMb7I7gBy3pvIW7Cys3yyaP+LEDS9K2ShvJmyx7y5mvN3rQZx5szz+fY c5plfGbgUWsUBjguFlYsWWFF185M2Tg7pixTI1NBVSO6NHOCMmBnqXjx0nM6QQepkmZxzII3 n0qyalJTM3A+vrj0zJI9cIs6CDNQB6E9+0AilM0M4y70C+Lec0vlrdX5MrkZiahY6u0NN3gD tjdse02ieKI/KKRUUMUy2bBhO050CY4RXQoo+q1rx87mQ1LNTG8+NeNLcycWA/YiZS9a9iKW WK3U1lTFgH6Lr4qhJky/FMvoHbJkV9ws9kMzRmA/1P74wLW18yzeO/WMTEPcu3j45rsJ9vDN hmSON15rvCnbmzVvzPbaxGsSzYb9kP5vCgaCQsmKKjtm1mW7gvlq1E4VVDWiSzMnIAP2QkWX Fy97AUvApmqTKmDAjltwLCvIqtENzcANmdInLUX2xnH2xgzU3ri7DIPLH3x4xkGCiJoHiTDZ NTK5OFem/lNkQyS5pTn25ktaeJOmWUFFP+OtBf02Tt3GY4BjZc367fgxPui3+WrkqqCqEV2a OUEY4IWpIqigSpBBqkEzOGYVjSfj7cWvBlVq1qoYyOaXjywZhIdqDsOs0y4QTcMglCietipX 1kAgGPkegzDNceVTuFOy82V1uTwaiL0Z87yNtXhxsXk03HAMxLuOxIurdQtUUNWaOi2oDCgD ykBSMODckCF9U9JlaMjIELR4KO7sQyGidoTrLd3ZOz3EFNXreoisr+H5CgLrq4J8+fpukdyk 6GniNDLejTpeXOK0WFtSZwZUUNWZQq1AGVAGlIGmZ+D61tIjPUW2xlzfQLRma2AQsB0BncQX 9JZbgIqIqOUQTrMgrmbCnVlSIjNvL5Sfvbz6TxlQBmrEgAqqGtGlmZUBZUAZaHwG+Mu6rhnS My1N+mDZrQ8W63pDBPWBCOoHYbQ1/APKRFO85hlZhemRHyG2fsQC3jxs8vmxxJE5d+ZKTrzs GqcMKAM1Z0AFVc050xLKgDKgDNQLA9lccmsl3UvTpRuW2bpjM1k3iKVuEErdIZC6QSj1QHwf iKFuWI7z9wfyN5EwpJfNONGP5bl1cBejzGIEF6PcYjwMaUFKrvyYLbIRcWrKgDLQgAzUm6DK zpL38IE/0mur4WcblwQYPuCeW0XYxUWA+dxIfvx4JBKO1vW7NFTOX1NEwc2Tfh3ecyVQp+ei zlLU5qWh3lIvjHxMpx+N9d3I8yjQDzzMFw9mQzzqi8KvrxQ1hXFsGx/1I55lUSbM4yBPGN8m vTD9XjzTWR550KFoWqlXZxht8tKQ4rsIe3EhhIt9P8MGYZOHOlAPnkoWzgfwvBeWwaHVlAFl oLEYyOYrj7KkXbhY2qemSHvInnb4vHfAtaUj2tAJH8jOcDsjTNcL0894XC/4HkP/4WmILLOI 33PwD+KI16lf4V2Ozz+X6X7FMZbjWvIL/Euwz2mx7nMqY089ykCTMFBvgqpc6x3BdQIf94CV CyC+2uHYiuKULTtMTKXlgpFAMM762ViaDZf5gxFejsg//3tiMMb3B+LLigbimMmLj8RFvmj6 ZcsFEBVvZMp+uOwXwWW7zDrAdzOAiy6FZwkO5Asy47u4eP8uDv3mE2IpHCkAfT/LRcqwnjKB 58dF6/BFZVkZCMdoGutAerljIo55oCApQH1ERCOPkcK2hANpNg9jrZ+iEiIS7ygpXYKGz8PD IJeBUohJNWWgMgacbDxLCW9BzQy1lox0VzLx+coopZsiGSlw3RDSjLTBZ6INzsc2EDBtcP62 xWehDc4/btz24nCQtkjPQnw7fD7aI097lPFEUVrZoy3LNwX5ypkN00V5vu1+NY73G13UTfc3 fH5W44P8G9JXu2H5dcEWWTnB/3KHZDVlQBlIRAbsZ7s+2+bVmR3RDnMj7vYRd2XE7RlxsYDv QDuE2vvhEK4u1DehzEi4KEscXKc4fxUqNr4LXeGF0egQ48vcdN+P6aUUxkOjeC5u4im4gHp5 Gcd0HgMXUFxLJQUZUzAlloKKvPxIo5tqEI8LXQouasyfArHiuagptcwP6WP9mDVKZTm0h/KI /hTm9VxfIvlpjp/PO46Nj8R55RjHsF+H78aLi58H1bYwwywmeszZOgyFlBbjxtmpcxcJpWLQ UzAEdAEHAx2Mc5iW4qcxnxdmXuTz0/z89HvhQLxNjxfvhELecb1yTsSPOC9s0xhGmo1jmbjA icBPhJcWcW3Yug4/MYE83ugzDoaSnst0LxxxY8OGzNHgBv1eFOmNF884F7+oJ0oxCWz9dE2c uEi66+XFRG04LFdfdZVsnSIvZjhSlB6SEny2S/EeGhcnvcEHkq3l59b/DPBZSMZ7HlI6ulXe z1kipvnPS7L+DMRloBJP8Hj9a4h/Bl88RDbh2JvR3k2gZZPn+s9m4vvrcnAd4V6l9ciXg+tP Di48OXh74fpsX1A1RKu0TmVAGWhkBvyrbCMfVA/XcAycBDHXHeILIhSrD5IaypJUzAyl4lt5 mndj4s0pXVLx7dwPU6hBbkI18n1qviBEGALTS2cdEQEZTUcctEC0PMVnMMwyTqC+QBg3lt8J RNyA/LrjC0Q/vy1n87DOSBxumDHzgA3Hr9acnAzgHCvEOVmI828LXYQ9Nyacj3OKyEMeTnzm 4dzKR14vDjNG+fgSlo/PTi409qZiVzZtyZfNY/0XOycnMdpqZUAZqDcGVFDVG5VaUSMyQAFF ocVFFv4cvC3+dUJEJwjArlgSfDZn3VpvBoSzIZwJIQxeLub5I3GcVXFL/TRv1sTmRT4/zc/v zb4wLRBv0z03Jp4zNWX1Mc3O3KCOsrQqZnHKyuDu7s0Oefnhj7hMLxePu75XBi7jaf7EHT2R cMT9XRhZvFkuFuKckOfAtX6oC/rL8vgZvHDZrBpn8YKzbJXMvnmzgZHZwn/dcw8ekCSvpTqS lwqxkgbRAhQgvCXVlcKQI8WAt7SMJpRg4qsIzSnGklix59LP3YWhSLgk4ke4MF+KMDW1JVtQ hnSoKQPKgDLQgAyooGpAcrXqBmPgd4IKR+KOMm4l48bfCWXLVgioJS4DEZGGiVVvSYy/RNsM 5AHcW0QhxL2AUI9qyoAyoAwkNgO6VJLY46OtSzAG1q5dK/PmzZMtWzAPpqYMKAPKgDKgDEQY UEGlp4IyUA0Gpk+fLttvv73svvvucuKJJ0qnTp3kpptuqkbJirMsWLBA3n777bgZvvrqK9lu u+3iptnIbbfdVh544AEb9NzCwkLJysqqsF5muuKKK+Qf//hHuXIaUAaUAWVAGVAGlIGWxwC/ CPAhEllAN2BrYBgwAvgTgBW/+rOVK1eatm3bmueee66s0mXLlpmtttrKPProo2VxNfW88MIL 5vDDD49bDMLILF++PG6ajbzxxhvNiBEjbNBzIdBMx44dTVFRUbn4YCAnJ8esX78+GNVkfo5V ZMw4dhxDjiXHlGPLMdYvfSBBTRlQBhKfAb1YJf4YaQubmIH77rtPDjjgADn99NPLWtKvXz95 +eWXpUuXLl5cfn6+jB49Wvr06SMQOfLNN9948XPmzJFzzjlH7rrrLhk4cKDstttuMnv2bJk/ f77ccMMNMm3aNLn00ku9MOsfN26cDB8+XBYuXChXX321V0cpNrNfc801AgEne+65pzz11FNe /KmnniqfffaZcBnS2uuvvy4nnHCCpKeny8cffyw77LCDtG/f3ptV++03PuJIBMJQXnvtNc+/ YsUKOeyww7wZN5Zj22gV9cdL1H/KgDKgDCgDyoAy0CwYaNQZqqOOOsrcfPPNlc7iQAyZ4447 zmB/lXnxxRe9WSLOBEEwmdTUVPPXv/7V/PTTT+b44483Rx99tDeDNHbsWAOhZjgDhiVFbxaM M07vv/++V27w4MHeMSHozE477WSwRGg++OADk5mZaSC4vLRddtnFPPbYY56/pKTEdO7c2Uyc ONH88ssvpkOHDgaiykBwmb/85S/miCOO8PJdfvnlZsyYMZ5/33339drG/BBwBoLPi6+oP15i Pf7D2agzVM3iI6mdUAaUAWVAGUhGBhpVUO23336GoqYi4/JZSkqKWbp0aVkWCqNnn33WE0YU OeFw2Ev78ssvzTbbbOP5g0t+FFQUXuvWrfPSKMSsoNp5553LLTc+/fTTZu7cuV4+zHyVCaVJ kyaZHj164EkOpeb2228vi2fG1atXU7iYTZs2GSuoKPBCeLwtNth7dRUUFJhbbrnFUAhW1B8v Yz3+Y5sALtPqkh9IUFMGlIHkZUCX/JJ37LTljcQAl+q4STzWIEjknXfekSVLluDxUK63HMdl OeLrr78Wu8TWrVs3gUDximMvVoW/EOzfv79AfMUeRrBfS4YMGVIWf+aZZ8rQoUO98J///GeZ PHmyQCgJl/tOPvlkPOk9JBB3XntsIbahTZs25ZYHWe+AAQMkI8N/kDhmvrzN6ixbWX9sneoq A8qAMqAMRBngwxHVlAFloBIGuA/pX//6F3e6l3u45R133OH98o9iB7NLnoihaKFt2LBBWrVq 5e1JosCpi/HXfqtWrSqr4pNPPvF+Acj9Wn379pU99tjD+1Xfm2++WbY3ir9I/OGHH8rKcK8U 20ZxaI31rlmzRrhHi4IPS4bevrA//OEPFfbHllVXGVAGlAFloDwDdbvSl69LQ8pAs2Tgwgsv lLS0NMnOzhYs3Xl95OMO3njjDW/DOWd5evXqJVjC89Lw6zxPaHEGqzKjCKvO86yOOeYYr278 cs8TVmeddZZgf1RZ1dycjj1enoDba6+9vHjs0xIKr59//tkLs70jR44sJwgpxtj2V1991cuD pURvxq22/SlrkHqUAWVAGVAGlAFlICkY4BeBRntsArcM2b1PrVu39h6XwEcmvPXWW2W7ibDs 5m0Ix2yVt7n8tttu89K4FwozXGX58Cs607t3by/MPVesB78C9DalDxo0qCxfcA8VZpe8Tek9 e/Y0EEHm/vvvL8tHD2aZvP1X+NVgufhzzz3X4Nd+BjNOBsuJZtasWV663UPFAB+zwEdCbL31 1t4xZs6c6eWpqD9eYj3+wzjqHqqk+MhpI5UBZaAqBpyqMmi6MpCADFBQlXuXH8IN/uoZ6Ahv PxP3F3HprNy77dAAziBxVgrCp+xxClVxx2W24uJibzmuqryc+WLddj9WVfmZzqXCjRs3Ch8C WlE5Hh+b4b26g3XWpj/B8tXx66tnqsOS5lEGlIFkYEAFVTKMkrYxloEmEVSxjdBw3RlQQVV3 DrUGZUAZSAwGdA9VYoyDtkIZUAaUAWVAGVAGkpgBFVRJPHjadGVAGVAGlAFlQBlIDAZUUCXG OGgrWhADeMhmud7yl4PcH1WRVZUerxz3P/HZVGrKgDKgDCgDjcOACqrG4VmPogx4DPABoXym FY3v4ONDOvHrPjnwwAM9Fy889tKqkz5q1CjvnX18WCifMcVHN+AXfJ6Q4rOl8Cocb8N7WYXq UQaUAWVAGWgwBlRQNRi1WrEyUJ4B/jrwqquu8l50zJTrrrvOe4DmokWLvKet83lQTzzxhPfE 8+qkMw/ry8vL815mjNfRCN4DKOPHjxc83sF76TFfyqymDCgDyoAy0PAMqKBqeI71CMqAxwDF TpcuXbxX0zCCr3jp3r27J6oYxouO5ZlnnhG+goZWVbqXKfCPD/vkQz6nTJnixZ533nmCdxB6 T0IPZFOvMqAMKAPKQAMwoK+eaQBStUplIB4DeKin9zwom3biiSfKFVdc4T3b6ogjjpCDDjpI Dj74YJssVaWXZYx4WP/LL7/sLfsxqmvXrp6YwouXy73XL7achpUBZUAZUAbqzoDOUNWdQ61B GagWAz/++KP3qheb+aKLLpKPP/7Ye2XMtdde672X79hjj5X169d7WapKZ6Y777zTe8Aon+e0 6667enVwlsoa92cF3+ln49VVBpQBZUAZqF8GVFDVL59amzJQIQN8ijpeO1MunZvRueeJLy+e NGmSUHTddNNNZXmqSucmdD7lnMjPz/cEWvv27cvK9+vXTzZv3lwWVo8yoAwoA8pAwzCggqph eNValYHfMcCXIdtHJvB1LxkZGbJ48eKyfMOHD5fRo0fLggULvF/nVZZuC2VmZkrnzp09MH+s 8ZeEfNmxmjKgDCgDykDDMqCCqmH51dqVgTIGdt55Z+Ev+mh4abG3r4m/wuOv/2gFBQUyceJE Yb6q0r0C1fi3bNky2X777auRU7MoA8qAMqAM1IUBFVR1YU/LKgM1YGC//fYrE1Qs9thjj8k3 33zj/epv9913lyFDhgh/qWefRVVVelWH5sM9c3JydIaqKqI0XRlQBpSBemBAX45cDyRqFY3O AL8I8BeqrYDWQFugHdAB6AxMMMbASSzjHqcdd9xRZs2aJe3asbkibCcfj5Cbmys77LCDpKSk lGt0VenlMscEJkyYIB999JE8/vjjMSmJE9SXIyfOWGhLlAFloG4MqKCqG39aumkYSEpBRaoe eeQRb5P41Vdf3eDMjRw5Up5++mnvCeoNfrBaHkAFVS2J02LKgDKQcAzokl/CDYk2qDkz8Je/ /EUGDhzY4F3cuHGjULTxdTRqyoAyoAwoAw3PgM5QNTzHeoT6Z6DGM1Tc+B12S6XURNyyMOLK /G7A78cH89NfGqmDZSoMI83FUl6p8evw/Yzz62c566cbTPf8OAYXLG1aPJdLgczr/ZXz++UY 76VH8lg/h4Jp1pDsmY2zS6XRsOA5V34eR/AXCfj+aDx9TOOf70cYfyEnBATdoD8k944dK9K3 w1uS6hRIasoWSQttgVskKU6hhEJFKFyMakpQZxhuqefST7ggmG5KJOzFh4rBQLGYiFvqlIgp RTgFCBejXoSLiqU0rVi2/FYs4xYhf4AQBNSUAWVAGagNAyqoasNaspUZPjxV+mPPUWsgHUgB QoADpBWneG5pepqklmADj4O9SWncn+TDmLQyv42jy7LBcDy/wZFCUr4845xAHMPxygbjeKyK 8hn0SCJtNKjXIG/YzWqT1dYTNBRRYQgcNWWgYgZMIdLiw8iWaJqzBeduPja+5eOcKxAJ+X7G uYhzgFBKPk48xEueOO4mCedvlrum56IOPQkrHgBNUQaaBQMNJaiC9fr+k3Apoq0d7rvb5vru hkJH2nQNScciXJaKcevMCknbEke2hB1JyQxJBlynOCTFrR1JL/X9JZlwS3CrdlFHGmYrwiHo AN8VuqVASkjcEG7WEX+KA7+L+BDiS+GHG0KcCfiZ7iKO8czjpUfK2XhPELCc6wsBh36KhEgc XSsA6KcwYN4yf0RAxIbxFdrL6wsJ67duVLzYckHB4R2jAmECFkl7SzfOkqTidEjBjInnYvj9 MOLK/KGA349n/vLpfh2M89PihL1TC8Rj+JmPxy7vZ5xfb3AGh/V5edFOfjiCaeVneXC6e7M+ nAPCXwV+lrGzRtbP84BlrCGLZzaO+WnRMKQDZrGiM1b+lBbD8Wa3ovn8MtHZNc6Y+bNxQfeK K68UGdjxWWmVukXSMSOVnlqCj3SJpKe4IA3EhdigiLiPc47bz4Mxkc+Igx8qeAIbQpti20lH ZyDqje/3viAgzoYd74cN7HLDGaf9PCHmbMJx+ZRVC4RlI+LwaPxQjucal/71uP6sFyecIwWy XsZ+RVGnpgwoAwnOQPTKWteG/mPEe7hoHFnXarR8QzBg/CUSb0kksDxinPJLKOXSKyjj5/GX YMrlD9TLeLs840aWa4Jx9BvE2zy2HhNTRzA+FFnewbqNN/WUj5WaDYUpsmFLKtxWsrGwteQW t5GikvYIj8/dlOsJJiuerFBoCHa1ztozEBmXk1ADBAXFhSc28uBiBkiKAJ67DTm748jZw1vh 96EZkF0ZkGwZkupm4tzEU1KdDN+lHzAmU4zTBiq1Dc7fNlC8cN1oWBAnTDf45amDn3EaAK4x WZ6yRSW1tALU8Rva8huO+xvq9P0u4gRhB64xv8pPOStkwlwuYaopA8pAEzDAb3X1b3YjBmt2 nOhXWi8c+V5rv8oy3fPj66uXFy7DFfkxj44LCOqEa8vRjyubFxd0vRt2JM0TD8yDi7NDIeEd h4KCcXSBSLz1e+WZD/H0G9zUPTcQ5gW/LC3k56EwCMYxD8vavDbMfFYoOCl+ut0XwjxMKycy ImLCi4OfLpFainwuj4F9JaUQHCVhKSoIy+pFYZng9Q2HblaGmUZv1iL2sQkUet6MXNtWmc2q w9qZBmPAyFNT7XJfQx3Ekav3xaM90tpLSmk7LAu2wyULrtMeV58OuB51BjrhmtQJn2e4gMPH f0TixGmN9AGIH4D4qHmTdwwikvHbdTVy44i1qGM56voVcb+i/uU41nJMvi/BtWGx3Pn52mgF 6lMGlIH6ZCD48azPerUuZaAhGahIUCX0c6gakpBkrTsBZqgSn7qLhreVTsXdxKR2wzIoXEK6 QZD5riPd0YneEFE9oawq/5JsDPZzOUuQF5DFHhzzk4QL58kdX3PGS00ZUAZqyYAKqloSp8Wa lAEVVE1Kf/0dXAVV/XGJmkKYCeuOPWi9MaMFpFBk9YG/HwTYQPgHwt+xwiMaswFp84AfMds9 D9tM50m4YJYKrQoZ0wRloBwDKqjK0aGBJGFABVWSDFRVzVRBVRVD9Zx+7X4dJS0N4qp0a+gv CCwZhBmrIRBQQyoUW8asQitmADOxtWAmfgM0Q/45dVk9t0yrUwaSngEVVEk/hC2yAyqomsmw q6BKoIH8+/Dukglh5TpDMdcFkSU7QGztAtHVPk4r10CEfQV8KU5omiw30yN70eJk1ShloGUw oIKqZYxzc+ulCqpmMqIqqBJ+IB0Zsw9mtNKH4cdAwyCw4Dq7odVbxbQcvy40mMVypmDz+0TZ tPJLPDSVv9JUUwZaDAMqqFrMUDerjqqgaibDqYIqSQfy2v0G4vm/+0Bc7YMe7AtgNgvzWtaM wbOznM+xRDgRP57+WG79YrZNUlcZaK4MqKBqriPbvPulgqqZjK8KqmYykJfu1U46tt4bS4Aj sUQ4EsuFO0NsRe8vRn7GDNebmMV6Sz6D0Jo6lc8XU1MGmhUD0RO+WXVLO9PMGVBB1UwGWAVV MxnI2G5ct39XPG/rIDwV7hCIqyMhrnoEsqxH3Lt4PtZLEFefqLgKMKPepGZABVVSD1+LbbwK qmYy9CqomslAVt4NR/4xYk/MTh2HbMdCXA2JZjfrsDQ4AUuDz8qtn34VjVefMpB8DKigSr4x 0xb7ezX4AMPYJ6Xrgz2T7OxQQZVkA1Yfzb1uv20lJRVvd3VOxfLg9tEqzXy88PFJcQuf0Wdf RVlRX/IwoIIqecZKWxplQGeoolwktU8FVVIPX90bf/3+O+EF2KdjluqMwLIg30f4vITNf+SO qT/U/SBagzLQOAyooGocnvUo9cuACqr65bPJalNB1WTUJ9aBT8Juq8HDj8CM1WgIq2PQOH7G sUpoPsJm9nvklk8/8cL6TxlIYAZUUCXw4GjTKmRABVWF1CRXggqq5BqvRmktH8mQnnY5Nq6f C4HVxjumMd/jRc/3yJeYudJfCDbKMOhBas6ACqqac6Ylmp4BFVRNPwb10gIVVPVCY/OsxHtN TupfMGN1KTqIFz/DjFko4mbLrZ+9hJDrxSXmv3j31nhxidn65tkqE6db8eLiZKtelA5w9XjS XInFAM/bijald0Laa8bU6+cksXrfjFoTEVQnokvrgY3AZiAPKAD4pG0+rygZB/MfaDefKM5f tl0MPAAcDEwGrL0Fz4fANIDvyusFrAasHQ/PU0A34O8A67sSmA/Q7OegxA/KT3B3BMhbeiQu 6HAp7d1gRFL4z98tTbq1wQb2lBvQ3m39NhvsrXKulVumvJcgfeBY2PtprN820abbsLqNy0Dw OmL9dOP5a9Uy3pTUlIFkZsB+IOjyG2sif2tNZp4bsu123IJj2ZDHa4q6KRbHAbsAVgDZdvAp 4hRDFFAP28hI+A24hYG4JfBbsbQ//BRI8d61x1/PzQOS3x6dTr6ekZOw3Df4wDMl5NwI7cIn s7+LxzFMxouer8KM1cwm6mhQPHHmnGHrWj+bFszHsFrjM2CvLzwyrzk2bP10OU42Ht6amQqq mvGluROLAXvi0+WHgShNrCZqa6rBAMfMjl9wTKtRNGmyfIaWcj/QZcC/47T6RcRxps4KqjT4 OaN0ClAbI4/Nyybws/3peDlpewirrhd6wsqRg8SEpsuNI56ScMF1jfy4BSuSrHCikCJSAq5N s3k5JvSrNR4D9rNgry281tBvrzvW5bgwzZotZ8NVuiqoqqRIMyQBA1ZI8YPhLRFhKUkvWkkw cGgiL1ocM46dvbDB2yztr+jVF8ALwMqYHnJP0I1AZyAHGAHw8QGTgNrYkSi0c6AgZ7neDIST 1zthLnm5Ty4f/rS0kzHQJ5cgfI6ktj5Rxgy/Rdbk3i/+rFZD95HXGMKKKAopgrORev0BCUlg vP50AOz1h022okoFFdlQazEM8ITnyW8FFZcGCH6r5zJIO4CzAq2BDIDf+vklghdAtcZjgOND 0cSx4Y2d+6PyAe6X2gTYcbOCivlrfDFDmUQ3LsGNBzhDdVpMYxciPAv4I8A8JwATAHJSGzsJ hciztQ3wNA9BZXt071QKl6tkzD6Y1Usf6z1uIeT8W7q1+z8Iq0vktqkTbdYGcK1gsmKK1xWC 1xhH93A2AOMNUGXkizcfEM1rkB1THomfO4ZrdB3iCaCWOAzMQVP+CfAb7FRgAMDXNNgLIwee N6SuwBXAfsCBQNBYljekUYCtrzf8twE0foOi2Qv17fDPBN5iZIzxWJkxcYkS5IlOWDEVhp/g hly2Ox2wfWUefqu1cSoM6elBAAAgAElEQVSoQEYjmh0jjgGxBaCgosux4pjZ8bOiyo4vkpqV 3YzecL/U8Di9sst+TyPtWOBPcfJUN+ocZPz/9s4ETorifP/NfQiCeN+LeN+Kt0EgajTiLRoh mkii+f2jEoxR44lRMMQrKlHRKNEgifG+4hUVUIwaxYt4RggoGhUPEDkElPk/3955tRlndmeX ZWF3n/fz+W5VV1VXVz/VXfVOdc/s6+UWbtDlhj41We0/UI/99tGIcIWmwU3kXD2i96tu1a+u n5xc8PR7S+H8mqlOxpGsQ8X4whhta1gK8GGb/sRi3Im5hbBss0NVtlTLpCArLGflKWwAg+/p YjUxPZ/JDd1H9MtvR3CRIoANF6zYHMtG3vhU/KrgRc+GYIUXPZMwMFkzOTNRhzMV6WjDp0fS 4+ZR1FYPCtBf9AOfAukjnKisU0WfkR79iAOW7WNtNhqbpTPhvr1SvFNwVrdomw8++wg0eUrY ylXg/LEPJz/rvpVWqPiwOVh3+RFJizb7abXqN3rQesVS+P2qcKoYUxhbcKaYnG0NS4HoM8Yc xp6gxmdhh6rGktXrDjhBp4obBY8EsqavDaff4jlY4R/zGXsqZNJ6JL/d2IO4AcJpYmDjmo7r OtKZvHGoSI9PlYra6kmBGKBYhcJxyjpVrL7GKlU4VeFQ1VPz6v0wo3TE/xN7ifsyR2cl5VnB twH/Jri+a2udtWOXgp1ZFcRRa7xW+e7URclZe9ycNG/OY8DDdMdfkuyROybZvdfPkwvGPVlH J1/oTOFQMcYsryv6dXTajbIa+owxh/kixqoIa3TCMfHUaCcXrjcFpulIvG/BALtvkaP+VWmH iXCoDlX8doFTVVPjnaMjC3bCiXu+IG152cw6U5xvLL0TYvH4j0EunCkcLjtUqFO/FoMTA1bW qWJyj9UqnCn6EWJgWxKHQtUst8Z5DRQ4T4XGPX2tYAV6SeypIjsfq7SRRdIbX9IFTzB29tXq 1L664zV+6mcWmueeSAb3GpXMXXBacslT0+vgpLNOFWOMV6jqQNRlUAUrVIxLMT4xR9TqKUat dloGJ9xUDjlRJ/o7waA6TlwveDGVx3GsVD0gmIBWFR+LruJNsbrgUcL74nDxuMCy9VWmlH7k xzELB3heYh0eOy5nYThGsSoVnxAZ1GJwIy3IOlO+7uu3M8P5jU+B4TgR4lThTEVIWgxu4Ygp yWYFaqnAwA3bJJ3WOV2O1emaJzV55mZq7e+c5I1xIzS6MonW1Bg/GE8YWxhvWOFoLzrmecIv pUuJBmD5L4PvoaZ+nocVc55oMB7Fh7uyP9h5hUqqLedGxw4SV4lxImtTtMEK0gHibUHZJ0Rt bKp2+m5tdlxG+8QkzeDGoBhOEulsQzhbhOFQUS7KKmqrBwXok+iv6JtwmrIrU5EWjhT72KzA kinwh0kaFyedp28Djk6atRmux4D7aQT4Q7Jpr58lg3OD9I+Xx9biADGO8MEuxhnmUxwsW8NS gD7DiaL/lmiesEPVMDr+fjXz5+LMIs29WWk89psibhFNZRLiPBnUmHzDSIvJmMk560gx8MUg aIcqFKufkH4Jon/CsSKMT4KRFn3KPjYrUDcKVH4bsI++Dcg3KH8vx2orDQljknN63ZHkFp2a DH1iStEDnd3rXK2hjkwuGvduQT7jCONKOFWxGl5QzJvLuQLRb+FMxVxR42bboaqxZMtsh5N0 5BeLHP1Wpf1W8Hs+fFuvtsbF1KXIzjOUtrxObNGu7AQcE3YMcjHohTPFKdqhKtLRSzEp+okQ 6CNCHCjiEUbfRTll2axAHStw/th7koEbPpR0Wvtk/dr6memL681aHCDH6mr9QM0FyaXjeJ2i 0s7osWpapm3yk+SMXvskw8a9EVmZMMYaxlDPqRlhGkiUPst++K51s935tZau3necpCPyPlPh KtUHSntGrCt4/Fdb21Q7flJk505Km1UkfXlIYuINY1KOyZqJORwoBjsstiu3/HdZKJB1lMKp ij6LkHZlyy2LdjbmYzJOdBBTBO9jZo17BVjdrS/j24gz8wfLxpfu8SsfAw5LTtv9z0mb1sM0 Ohwlx+ok/QzwT/Qi+0XJgoXDk4v++XnSsuUANYR3MtfTG1Pjk7N69EkuGP9cvnExphCGdkzM toalAH0W/Zft0xqfBTvbrEBjUCBuBM6lMB7n5+s9lKj/8GIdcrb4Tf7QOE1Y1nnKxitzq//b X0X4ksYVmaKnKr5NZpsPGpfltw9SyD44dDeIfwiM9yj4/aKeYrIYJt4TWKn62GdkWuKbP1cr +pTYQ/zsm+Q09mP9xfHfWJwgNhJjxaWC9mA/EYcIXo7lcT6P+3kkWlX7qqpPu6b/MeAChWuL dwT17SmmCs6N88VY4ebVgu+zsRRsV9WJ5nx4W1XwJRs0Pi4TP1jx+rcze2ydtGjxOzlVce6f JrkcP7twjBrT7esG5fSDtLmvDtXjQfqNPuFldBxUfjMQh5BV/jv8UrpUaACWfymdV2Y+FTj2 LB4wTnH/8U4yHy5yoizzClVZMrlQA1CAiz574RdznoqlNYBTaxRNPF9ngdNQuPqR7bOanOjm KozjgRP0t4Idf6ztoYKBEfugMkidpWsUP0vgRIwWPxA4QDh8Owh9EyzpLsaKLQTOR6n6NlDe luJsEfZ2PtJLIQP0Q/ltAs6fyfde8aigHecJnIvTBG05Nw/tu1KsLq4VpdrHpF6qPmWlx7tH ISvbT4vtxftiiFhXjBQ4MbR1adsLOsBe+YOgcWvBsffNxBVdBvbb8RN1VH4EtJce8dEne8iZ QqPFrRn/yqr535PT9xiQ/O4JdGdMydJ88R281QAUoM+yfVgYzzWAc3ATrYAVaIQKrKJzwgFg 0mZlaGeB/UIcm8Yqv616lOIvif8IPiGGMfGzYpG1o7WxdzZB8f0Eq04TBI5HGIMhxy5mfGnj V5kM9rtOtBALBA5G2HRFOGZV9e2vfPYvZqOU+L0iGZzrM5n0norzqJ1B/XpxkggbqMhjoqr2 VVUf9bD6heOJjRBXi4sEq0M9xCDRT2AHijFipPhIPC42EtiJef6iMBzI8xR/Q9CP9FvYg4rg KNE3UwT7YluKv4qu4jUxS9AnEee4hba2Eh4WrCDcKbYR2Jri7+IzwfF7CWxrcbM4Q0wStwv2 4VzeFtn+12YJO6d3T728/qHIFeWcXouS075DXTi83cR2orfoK7RAZWsICtBX+T6j7+hD+pI+ 7Shw+Lkvy7YaFS67Vhe0AlagqSrw/3TicwUT25/EHwXWVayfxpJkV4XHCCYfVmlwJBi8MByb hWnsmz87KrrpN5tpDIfgl2JsQToT7ZeCifTfghWplQTGYMnkGzZZERyG9cRsMU2EMRlvLKqq b0PlU+d48aw4QYSR/iPB8Vil4hww9ilsQxelrSIGi6yDhsND3VW1r6r6tGu6KnePwjUEuh8v LhG7iacFjuNqIoyJ5WOxZz4cnc/AsTk/n4YTxOTD47FDxQ8E9Yazs5XiZ4gBgmNdIdoLJqnt xbvi9wJH6teZ+LmKFxrHwmmj7rdEOF2k078VYqi4Q3COWkFKf4uPSbG/4Lp5QtAG2nixoB1V 27z5r8stWgnXqGTBtq0uSU75zmkl853R5BSwQ9U0uryzTpNBjoHbZgWWpgJMvBX5A1ylsF8+ XhgweeK03CaeFHsIjAn4RiK1tA20XwdxtzhdMBH/TWAV4jMieZumkLIVIpuuzXTSZ3Kuqr6u yscR5FxuFOeLYwXGfh+IgQLH7TGxjqgQs0TYe4owaXOs/4k5AufjGrGzwIGoEKXaR16p+pSV /vjkIoWHiYdJkO0kxggcT3R/UIRxnLPERDFIUBZHBXtOkIZjQzkcFpyijwTn0V2Ena0IDg/X ADpsJMIWKsIq4jwxNRPH0coaDi1O4K8FffUbcY+grt3FMDFD3C5eEX0E9rk4WTwrOM9xgtWt +wUaZ9uizSLWtvUAPfJrJZoVydW6ZT69fauTk1/tNkRlipcrurMTG6sCLZfyiXEz3CD4lFCX trYqGy4YJMIYGH4WG/nwxwq/EtyYJwhupLHiUrFIYAcJBga2aes/BFZVfacqf5u0VOWf5xVc JtoIBsCsXa2NpwR5vxQ9xWTBYPCewLYTDAAMXPcKJgAGKaxU+6qqr3LPync/jtQGgwjHYnBc TZwnGJiWhqE1/c15FNrSuh4YiPm0zABuW7YKDNXhuY/eF0+KiwWTbqExKYdNVYQJ8tFIUMg9 Hg7AmorPF/8ncAK2FaWMY3YRuXwB7qN/iZXFXMFKUNgKikwSTOzkZw2nhvu0qvoGKZ+JlGON EThRjCXXi7VEtIE6+oj9BW3IHqudthcKHAZsC/F3MUEwLnwq0CK7jzZTp4v2rV6QV1hfjHMz VI76mosjxJuip9hQ/EeEPa0IGmPvio8FemKMc2FoNlgcKmaKtiJrjDlhsxWhXTW1Cu0wRXyR 35Fj4rx8T7whZomw/yqymnhNcO3FeXPdvCrCOLdWsVEibCaH6bgSed9OXqFNv+RXu6+aXPOv i5M5Id23izml8SvQcimf4guqf686PEZH1XWUOFowEGStlza4sR/KJHJTdRD3ikfFWQJnYlVx mmBAuUaQzuA0WvxAPCV6iWL1KblWL6lerP12EKeL7mKsYPBk4H5E/EmwDP5zcbDYU1TVvlL1 LdR+2B/EJNFHMCFxzueLtQUaMDiF86honRnn9iOB5oVW19dD1L+bIh/EhsNlqsBXOvq+AseF e2mUWF8U2opKmJ5P3ErhzQUFPtH28fk0HJd3xR0il08rFeDM4zQwsWJTxVzB9f6OyLalQtuU I52xpYv4VGBdBRNxVfX1Uv7LAmcFmyKov5PgPhgjMNo8VXBOrcW2IqxCERwaZmLGNO6bU8Xt Iqyq9nE/l6qP/f8pGAOolzHlLnGuuFBsLxhvska/haFHC4HzVWhnKmElsZGYJe4TWWPsXVLD aVpN0AauKxwhrqmxgjGNfo7jbKL4nwVG2drbGTt10Q99jkxyzVonzXLqL4WJwmbNdfz8dm5R Wx2lrR4JtlHvtktaNOuc9N/2qOS6CehsswJLrMAvVcMrYoo4JV/blgr/mo8PVsgA+YD4n7hc tBRYDxE3Q5qgPxuLs2MjH66l8DLB4BuDcT4rHbi/FxuZ8DDFn8ls91ScgY2b8RbxKxF2pSLX 5TdGKSxWXzOlv58vUxjsr4TYP5vHgLBArJtJpP17i33EPzPpayjOIMHAVqp9VdVHVbuKvxCR fV+MFycINB4uGIzuFGEMyg8LJhPStxHYCuJ6MU0wiO0ksK3FDeLX4r/iecE+TD5sfyb+kN+m HQPFOJG9HjiHCwU6PCuOEbRjgugswnB4DxH011DxP/Ge4NqgL7C7Rbc0Vjl5MBDTZs61XT6d Nj8uSL9RrCiKGZNPsf25Fri+Obc7xOoCO1kwAd4qJovTRD/xpnhZ7CCaknEdcR9gHcSHgmuZ +3aIwOYLJmSMiXCOoH+w3cV2aeybP/Qj11Axu1iJV2YyeinO/dlJtBDnizsFdop4WnAtbSTe EnsJjGuQfOwIQbsZn3qJUvVdpbxRAuMcqftI0VpwjYYOOyr+uUCPrgLnbmPRXrD/tQLjnvqt ID1oqzhWqn1V1cd+q4l/CdpQaDhi3FthBypC39AX3Ftcy6HdMMVpW9gjivw0v0EbPs1sv6v4 Zvk8gjfFLmJXwb2FcZ8xpmDZONvoT7sx7iGcKOxYcUsaS5IXFB6ejzOufiTQnWP8W4RxfWTb PVXbO0dmLUOuH47VUTAOdBNcs71FX9EQ3sd2Gyvfj8vl+4y+ow/pS/qUvqWP6et6NyZSLmIm RJyjaWJjkb2BRmt7pugpthCviQMFtpv4Yxr75g/1jP9mc7EYg8P0xVIqnRKO8ZJ4SMQA8mvF rxFh6yiCiNywE8SeIuyXiozLb/xTYbH61lI653e74JypeyWBnSTGCNrNAHiCwGLAqdyq/PuU AvJXFHRgGIPEq/mNUu2rqj52/Y0IbccpTv9gj4v9RJt8XEFqT+rvFYKB6ULBcTHO/y7B4Hik +FR0EfTrQsE+9POd4j7RWqABx1lTbC8+F2jyfZG9Hn6h7ZcFE9u+Yq7YUKApx8K4qElfQ5wo nhO0cRPxujhGYO+KrcT6YrY4QNBmJjj6f0XxkcD5qRBca3eLQiu1P8ecIfYWTJz0+QMCw1Eg jzYfLBYJ9NxJXCWinKJNwvroLOkztH9FDBEYOkV8vuIPCvp6pjhHhN2myKWxkQ9r4lCxy00C x/5tMU10FxjXJ8fF2ZkjLhFhmyvygWA/2rSnCCtV3wYq8KLgOqY++noFgf1IUBd5C8RJImyg ItwX7wv27ySwNwRjU5bnyZBV1b5S9VXuWTnW3aUNtD1f/FbcIq4Tq4uwAxV5RrwpaPt0sYPA hgn2CztIEdpPP3O9Xy7Yp7PgfuT+C6O+XUT2/uc6GZsvkI2TxPXRM593gEK0miTQcluBHSrQ HP0+FGiAcQyuq7CLFcm2e6q2d47MWoZ2qBqJO6b+517rK3qL7UQ3wT3RUTBeLBOH6rs6MBd1 XOw4LUxi2RtotLavEGEMONfGRpGwh9LGF0knaUfBzZ41bm4GSPa7SswStGOEuEiENVNkkegq PhYxYCiaCjuBiKxUfd9R3gxxlGAgYEB5WGCcH4MLehwvPhHHCjprisjardo4LZugeH/xqeiX Ty/VvurqYwLYSqwhJuXraqGQ+toL9j9LYBuLr0RbNmTtBBPcSuJLUSHCxijCedOv1EWd2G7i P2mssu0P5uPbK8TxWjm/zX5MGthL4odprPIP18Pm4mzxl8qk9JPpo/k45Qfk4wQnitCdAZzz 5ZzuFmH0LTcLffCvSFS4imCSWyGTRrTU/mcqL+sYccNxI3KNXyauF2FcN3FenO+kyGhCIdfO dqJNiXOer3T6YC1R2AcldqlxMgNiN1FsQFxP6bSx0LieNxUtCzO0XV19qxXZh2NvIrinCo36 NihMrGa7uvZVVx/9sY3oKppVcSzyqKuYDtndOC+0DCumQeQtScjExrVSaFw7W4sOhRlLeZt+ pU30IWMB1xnXe2/BeNNI3I3Gfxr0Vb7P6Dv6kL6kT+nbGjtU1d0wqrMsY6IdJZ4QH4k/i6Gi 0N7KJOBgFDoUZP9NbCmY+DmxVwQ2SDyWxor/4YZDHOxJ0UfsL+aKmNAVTQe3hQqnCfIY2MO4 QWMCLFXfNSrTRcSxOF8ma45BGxmMyEMTBqX+4kyRbYM20/ObTETGQPdXsZWg3U8LrFT75imv qvreVf7aAo2pG7jRSe8kzhC/EFiFoNwXAqPuIaK7YOB4VoShz/2Cdn8ovhLYbFFs0iBvqviE SIFVaPv1TBrXD0bfoGdLcbC4WWAVgvSw/yqyamzkwwqF2TonaBt+J9B2ugjj3NBwTiQorBDF 9r9O6VkdOHf2i+Oja9gCRV7Lb6APN2VTsxk6YajO/lddgSXI/1z7QjF7p1ii0uivcPgLi9Sm vkWq5M3CivLbVdVXYpdaty/qw5F9OTaqCBm/uL+qM8aKrJbZ+6u6fWuSzz1V7FrhHpxYk4pc 1gosTQWYVOrCmKTPFUwwJ4qjxUGi0PD6wpjgmJgK7UIlHC9+Lybn42yzQlHKOH7vTCYDwlTB RP62qBBhFYr8R3wpGAzWF2EVijAZVlUfn2A3E2FTFcHxYXDpJTqLsCmK0AaOw7njiIV1VeRV geNwq/hYoMnTIqxU+6qqj30fEv0Ejs5Qcb9oJW4T94gbREwchKuJFgKj3FHiM4FGtJN8WEeM EBiTxZIYx10zU8Heiq8r3hJTxXfFnuJOgaEVxw/bRJGsVqTjDGXr3EjbPQTn8g8R50G4nsCp zlqp/QuPjbM6R8Sks6RaZNvQFOJck3Obwon6HK2AFWg6CjSvo1M9XPVcJVhdeFCwKpB1HrSZ 2qH6iwPRQRwmnhQYk1s4YC8q/oTgkxQTIXHAMSll85Rxk9g/X2BHhd0FbblP7CY2Fu3F6eIp gfF46BiBDky+OBLkVVXfGsp/TOB0tRAniocFEwQ6XCEwVr6o7w7Bp6vnxE8EdoQgf5L4nthQ nCqojzZCM1GqfVXVp93Sd5hwjFiF+qPYS9woLhAcj3MIe0cRHL+++YQfKzwgn/aewv75dJyd VwWOTFX2pTLbVVUgn0e/UHcbgRP0ZzFTYLeIiwQO0wyB/V0cLdoKtKGvHxFZo8yeYn2BlvTF 6mKs6C24zjCOO07kBM7RIQIrtT/pewvqxQ4Ujwr2t9VcgSHaxQ5VzXXzHlagwSgwe/bs5Kuv vkrbS8i2rTwFcC4mi6mCSfBxweOhXQUrEdhowcTGp/r3xWMCxwHDwZiWxr7500PR8d9sLhbD YZq+WErtXgJtrTpwunAc5ohLRNiPFKGtL4sF4iQRdpMi5L0taDfOG7aBwCFkH+p7QKADtrn4 QLAfjsOeAhsimJgLoa6q2leqPu2WWnP9PUcw8eNYnCluFPeK3UXWcKA+Fzh4tH1bgeGEfCxe E+SfJTD69d9prPLP1grQAasQH4o/ie3FWyIsez2spUSOhfboOFCEVSiCHkdGgsJ1BO14V3BN 4eSE40baVgIbIXCI0flu0UJgQ8V8QR0cj+sLwznKXkul9h+pcuzP9T1FbCOwy8TgNFb5h7q3 y2/vpBCH1WYFrEDjUYCxlbG5o1hddBPc871FX7FcvXz0zjvvpHPLSiutlOvSpUuuffv2uU03 3TR377331mk711577dzEiRPTOgcOHJhbd911c9OmTcvdc889ufXXXz83cuTIOj1eXVRGX+X7 jL6jD+lL+pS+pY/p62ViHHxLQWOKGQ7VzwUOBpPp0jBOfhMRE232GAi0QTYhE19P8ZUy2xGt rj7ELyY49a0WlWRCJnceGbbMpJUTLdW+cuprpgN0FTgAbao4GP1XrF/YB4dplSr2LcxqpYRw JAvzCrfXVQLnUY7F+RZrZ3Z/Vkc7ZRPycc4BHTjXqqzU/mtqp81Eue2t6hjOswJWoGEqwJjP GNKgHKr58+enPohWi3JDhgxJnauFCxfWhV+S1vH222/n4hgdOnTIvfnmm2n6gAEDckOHDq2z 49RlRerD5dahqu7WCIequnLOtwJWwApYASuwvCrQoB0qHJIxY8Z87VC9/vrruf79++eGDx+e 69mzZ+qvPPDAA2mcVaYf/vCHuY8++ihNv/TSS3NXXXVVrm/fvrm11lord8QRR+TmzZuX5h10 0EG5SZMmpeWbN2+e23HHHXOXXHJJbtVVV8117do1d9NNN6Xllqc/usAarEN1qBq/w/J6h7hd VsAKWAErYAXKUKBBOlTXXXdd7oYbbsjhFG2xxRa5Cy64IPVtnn/++RwrSr17987hSC1atCjN v++++3Iffvhh6iCdffbZadmTTjop16lTp9ztt9+ee/zxx3MVFRW5UaNGpXnxyI9HjG3bts09 99xzuenTp+cOOeSQ3HnnnZebMWPG8uRLpW1RX9epQ1XTR09lXGsli9xZMscZVsAKWAErYAWs wFJT4JFHHkm0cpRoRSmZNWtW8tJLLyVyntLjffHFF8ltt92WrLzyysncuXOTESNGJD169EgW LFiQbLjhhskzzzzzdbu0KpUcdthh6fbBBx+cvPFGvCZdWUSrWgn/O1rOVrLKKqskHTt2TLRK lXTu3PnrOhprpD4dqsaqoc/LClgBK2AFrMByrYAeuSWtW1e+PorTtO222ybjx49PHR6cH5wp rF27dsmECROS4447Lvnss88SPdpLHaI4ObbDVlhhhdQBi+2mHhZ7obqpa+LztwJWwApYASvQ aBXQN/3SFaSXX375W+eIk3XhhRcm999/f/L+++8ngwYNSlecoiCrXLbiCliZ4ro41QpYAStg BaxAo1Fgzpw56WqS3mtKHSYcp/322+9b58cjvG222Sbp1q1b8uWXXya33HILvwPxrXJO+LYC dqi+rYlTrIAVsAJWwAo0KgX0G1QJj+jWWWedZPTo0cmNN96Yvh9VeJKHH354MnXq1KR79+7J lltumb5L9eKLLyb6PanCot4uUIDfKLJZAStgBayAFbAC5SnAQgTvH/Mbfe1FB7Gi4K1rXkS6 rTGs6EyePDnRD3ImLVu2TF9i5/0rfXtPp9d4jJfnZYeLT8RMMUvMFnMFP+T8pah8c1+R6swv pVenkPOtgBWwAlbACjQxBXjkF7biiviLtuoU8CO/6hRyvhWwAlbAClgBK2AFqlHADlU1Ajnb ClgBK2AFrIAVsALVKWCHqjqFnG8FrIAVsAJWwApYgWoUsENVjUDOtgJWwApYASvQ2BQ46qij 0h/61L+dSb/9p38dk+hfy6Q/5sm57rLLLgl5/OAn71Dxg56nnHJKon+unP7a+iabbJL+RlVW l3322Sfp169fNslxK2AFrIAVsAJWwAoUVYCFCH5yvKNYXfD29nait+grlrv/WVesQfzT4zPO OOPrLP7X3kYbbZS77LLL0rSdd955sX9orH9Vk9M3/XIPPfRQmq9/R5Nr1apVbuzYsen2tdde m1tzzTVzn3zySbrdEP7QV/k+o+/oQ/qSPqVv6eMaLTrVqLAqt1kBK2AFrIAVsAKNTAH+1x6r S3KQip7ZZpttlv5vvvxPDSRyuJJTTz01GTBgQPLKK6+kq1fXX399wu9dNVXzzyY01Z73eVsB K2AFrIAVyCvAv6HhV9F57BfGr6nza+nz589PHn300fRHQXv3ZjGn0s4999z0X9TgXPXv37/o L69H2aYQeoWqKfSyz9EKWAErYAWsQIECw4YNS/9PH6tO22+/fbLeeust9g7UxIkTk4cffjgZ M2ZMMmXKlGTmzJkJP/gZxo997rXXXum/tOnTp08kO7QCVsAKWAErYAWsQLUKNJp3qLQalfv4 449T5s2bt9hrT4XvUJFJ+RNOOOHrcnK4cu3atcsdd9xxuYqKipz+X+DXeQ0hop72O1TVXu4u YAWsgBWwAlbACjUiw0MAAAaYSURBVFSpgJyh9Ft8fJOvnH8rs/nmmyc8GsT4tt9Pf/rT5Pjj j09GjBiRdOrUKRk8eHCVx2vsmX7k19h72OdnBayAFbACVqAWCvDu1Ny5cxOtPCV33XVXom8A fv2e1OWXX55Mnz49Oe+885IWLVokV199dTJ8+PDkhRdeqMWRGscudqgaRz/6LKyAFbACVsAK 1KkCxx57bPobVfwe1aBBg5K99947Ofnkk9P3qFiNuvLKK9N8DrrbbrslRx99dKLHf+nqVZ02 pIFUlv6r5QbSVjfTClgBK2AFrMCyVoCFCL4h30a0Fx0E/z24s1hZ3Kb3hxTYlncF8j8Bcbja +YmYKWaJ2WKumC++FItEWeYVqrJkciErYAWsgBWwAlbACpRWwA5VaW2cYwWsgBWwAlbACliB shSwQ1WWTC5kBayAFbACVsAKWIHSCtihKq2Nc6yAFbACVsAKWAErUJYCdqjKksmFrIAVsAJW wApYAStQWgE7VKW1cY4VsAJWwApYAStgBcpSwA5VWTK5kBWwAlbAClgBK2AFSitgh6q0Ns6x AlbAClgBK2AFrEBZCtihKksmF7ICVsAKWAErYAWsQGkF7FCV1sY5VsAKWAErYAWsgBUoSwE7 VGXJ5EJWwApYAStgBayAFSitgB2q0to4xwpYAStgBayAFbACZSlgh6osmVzIClgBK2AFrIAV sAKlFbBDVVob51gBK2AFrIAVsAJWoCwF7FCVJZMLWQErYAWsgBWwAlagtAJ2qEpr4xwrYAWs gBWwAlbACpSlgB2qsmRyIStgBayAFbACVsAKlFbADlVpbZxjBayAFbACVsAKWIGyFLBDVZZM LmQFrIAVsAJWwApYgdIK2KEqrY1zrIAVsAJWwApYAStQlgJ2qMqSyYWsgBWwAlbAClgBK1Ba ATtUpbVxjhWwAlbACliBQgVySijFosLC3l7uFaDPSvUn6WWbHaqypXJBK2AFrIAVsAKLKZCd iJmY7VAtJk+D2Ih+y/ZlrRpuh6pWsnknK2AFrIAVaOIKZCfgmJS/auKaNMTTp8+i/7J9WuNz aVnjPbyDFbACVsAKWAErEAowGTMpw5ci10ym0Lb8K4ADRZ9F/9GXtTY7VLWWzjtaAStgBaxA E1aAyThWNpiQF+b5gcJOYkWxgmgv2opWgjnXT4YkQj0afYTTRP98IeaKOWKW+ExEv9GH0Z/0 bY3NDlWNJfMOVsAKWAEr0MQViEdDTMCxMsWkPV8wabcWLQRGmQUi0uxQoUr9WfQRfQDzBA4V IX1Fn9F3sVJF+ehfRcs3O1Tla+WSVsAKWAErYAVisiWMyRqnismayZmJOpypSMeZYoWKdD8O lAj1aPQT/cBKFH2EE5V1qugz0ikDWYeKfcs2O1RlS+WCVsAKWAErYAW+ViDrUDEh4ywxp8a8 Gs4UkzcOFemsTnmFSiLUo+EgAStQ9FPWqeLxX6xShVMVDpWyambR8TXby6WtgBWwAlbACjRd BbLOFCsfOEk4VOEsxeM/HKlwpiI/yijLVg8KhEOFg5t1quLxLA4vzlThu1Q1Wp3iPOxQoYLN ClgBK2AFrEDNFCh0quJRXqyGMGHzmC8e9eFIQZRT1FYPCkQ/0S84VeE4EcbjPkK2s4/8tFkz s0NVM71c2gpYAStgBaxATNI4R0zC4SSRzjbEI0DCWJ2iXJRV1FYPCtAn0V/RN/ECenZlKtJi RYt9amR2qGoklwtbAStgBayAFUgnaBwjJt+wmLRjhSrrSMXKlB2qUKv+wnCosv0TjhVhrExF WvSpHar66yMfyQpYAStgBZqwAjHhZidg4oADhUOFA5V1prTpFSpEqEeLfiIE+ocQB4p4hNF3 UU5ZNTMvPdZML5e2AlbAClgBKxAKZFecwnGKMJwpymbLxb4O61eBrKMUTlXWwSINy5arTCnz rx2qMoVyMStgBayAFbACJRTIOkyF8djF820osWxCHKWwiGedp2w8ytUodAfXSC4XtgJWwApY AStQrQLF5tZiadVW5AJ1pkA4UdkKi6Vl8x23AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbAC VsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbA ClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApY AStgBayAFbACVsAKWAErYAWsgBWwAlbACliBxq3A/wf7XtEbk5hacAAAAABJRU5ErkJggg== --------------050403010308000002090704 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example-5.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example-5.png" iVBORw0KGgoAAAANSUhEUgAAAk0AAAEwCAYAAACqrkXaAAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB5wURfr9emYjWTIo AqKiiDmdiorpzDmd4czn35zOM4c16yXvzKeeImYx5zNijkQBAZEgsiw5LLvszu52/d/rntrp HXdhNsww4fv297ZCV1VXvaru+qaqukpERRlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZ UAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFl QBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpQBZUAZUAaU AWVAGVAGlAFlQBlQBpQBZUAZUAaUAWVAGVAGlAFlQBlQBpSBdcqAs07vnkY3L+rrusiO8pFG ddIGWTFVpaFQG6STcUloe864KkskwznbnhMhR8MoA6lgIC8VN8mQezir56nOlCF1lVA2i9c3 uVyh2p4TaiWZEyjH23PmVJTmNKsZyMlf4Vldo1o4ZUAZUAaUAWVAGUgKA6o0JYVWTVQZUAaU AWVAGVAGso0BVZqyrUa1PMqAMqAMKAPKgDKQFAZUaUoKrZqoMqAMKAPKgDKgDGQbA6o0ZVuN anmUAWVAGVAGlAFlICkMqNKUFFo1UWVAGVAGlAFlQBnINgZUacq2GtXyKAPKgDKgDCgDykBS GFClKSm0aqLKgDKgDCgDyoAykG0MqNKUbTWq5VEGlAFlQBlQBpSBpDCgSlNSaNVElQFlQBlQ BpQBZSDbGFClKdtqVMujDCgDyoAyoAwoA0lhQJWmpNCqiSoDyoAyoAwoA8pAtjGgSlO21aiW RxlQBpQBZUAZUAaSwoAqTUmhVRNVBpQBZUAZUAaUgWxjQJWmLKjR+QuMrF5tMqokkUhm5Tej yM3wzGp7zvAK1OwrA1nMgCpN66Byz7jQSPH6MWy8g5HLrjNSW+srEpVQgNr3M3LqeQ0Vi7fe M/K7/WN+Dz1uZNcDjBxwrMgWu4kceYqRBYti14NF22TH2P14716bGTnweCO/ljYePhi3re1L lhrpt5WIMam/d1uXRdMT0fas7VmfA2UgVxhQpWkd1PSYCSLPPSqyep4jK2b59nc+FPnrvX5m JkwSad9O5NV3RJYuiykWYyeKbAdlg/LBJ0ZeflPkjWdEJnzqyOQvRObNFxnxrH89+H/hYipH IqWT/XvyvhM/Qzzc59EngyFTY/9+vMg2W4o4jpOaG+pdksqAtmdtz0ltYJq4MpBGDKjSlOLK KF9lZPrPMeWnoMCRHbZx5GSMFn34iZ8ZKkcH7iOy5eYiz74cyyA7p+239t03/VVkf4Tp1tVX PIqLHbnzepH9hsfCW9tYxBs0UGS9LjElpVcPR/qtL7JBXz/UYoz+nHmREY567X+skRkzY8ra c68Y2XoP/9p1t8X8X3rDyPZ7G+k52MgpGBWrqPSv3X63gTJm5ORzjDyI0bDqaiOX32Bk6DAj x59p5P3RsXLYPKqZmQxoe9b2nJktV3OtDLSMAVWaWsZbi2ON+0Gke1eBwhJTYJhYcZFIQaGf LJWcbTGidMZJIo9jJMnKOI40RZWm9fuI/A0jU1RGOOpUVWVk7z0cjEQ1TJdxqWxxhIrriIjS MoNRLSPLV4j84Sg/9cNxrwEbivxvlK+snfNn3/+FV43c8nfk4z6MYt0v8sBjIt+PN/L5N0Zu v1tk5ANwfyTy43SRR0b6cd75QOTfD4tsPRRThgeLnH+FyM+zRf7zT5FePUXu/29MafRj6P9M ZUDbs7bnTG27mm9lQBloBQNFfV0ssUm+3P2gaw498bf3uvga11x6re+/9R6u+eQL16wsd023 jV3zzRjXzJ3nmk4DXBOJ+GFWrHTNvY+4Zpf9XVO8vms2GOqap1/8bbos0VGnuoblC4Jxxv/g h3/zf6457oxY3LETXbPhVq6prXVNvy2Rly9j1x54zDUzZ7vm4D+45oNPYv5X3+Kac/7smpoa 13Qe6Jp3P/SvzfnVT2NVhe+e9pOfD6aRbGF5W9EkMjqqtudY+9L2nNFNWTOvDKQVAzrSlOLq CK5LsreuqzPy7ocifzxeZFWFkZ9m+qM0HTs4cuzh/mgT43G6Lj/fH0nq1NGRC85y5Mt3HZn6 jciw33HUyabY0OTI1ZtY67T4Jx8/foURnx4iT7/oh7vz3yKffCmy0XbGw2En+iNCX3yL0a8C kd2RtpVzT3dkGUaoZv0isvfu1ldkZbkIR7+m4h49umHqcG8/n/dj7dZJmHps3853F2I0rUtn kYH9fzsiFktNbZnCgLZnbc+Z0lY1n8pAWzCgSlNbsNiMNDhVxqm3oIx8XqRTR/hv6QinOzhN 1rmTr1Rwim7Ua1BqsNDbTs3xC7r3R8cGUTbEVN8fj/On+ILp0s6puLKFIjtt5ysuVF4GbOjI bjuL5OX5oXnPt5GHqV/7mIR7fYx7/vSzSJ9esQXb/DLv0y+NjEf4Xt1j/jU1vtJ32gki3hRi oHzjsdicCpqVV97SqTnLRTaY2p61PWdDO9YyKAOJMqBKU6JMtUG45SuMzJwdU5o4qvTAY0Zu w1qfx+7xb8BRIfuFHH123NbBqAy+cnsKi6ejygjVqQ8/9cPzPxfjPjwSIzrHxPysjeltvJEI R62CUrZAZBP4Y4oMChpGjuZwVMmRskUiO/9evMXq9F8I97LlRjgadu7lIivKRdrhy75SxKc/ 5bGnRfbCqNMGfX2lj1/GWenQXmQK1ju5mCmbN58Lw3URuOUm001tz9qeM70Na/6VgeYyEB1r aG40Dd8SBjgKQxm8E/8bbxRnz11FXofSMWSwr9RQydk2oHQwJEebLrsuNtJ0yzWCr9WwJcHb +HINIz5V1SL77ilyw18YuqFw+iQ+PYaYPVfwtZs/WnTtZfz6TeTv9xlZslTk9uv9Ua9NNjJy 94OYFhzmT9cdvJ/Iofs7mIoz8s8H/L2hGIZTbo/f69+Xo1BXXBTLw0V/Ejn8jyJffitCBWoD TOHZEbNYKLVlIgPanrU9Z2K71TwrA61hoOHwQ2tSyvC4XDjL/YsyRbgDOLcu6Lreb7/Ea0kZ Fi3BNB5GjwZv7I84BdP4ZZ7xlJ1QKMYPR554f65P6tMr5h+MZ+0ckVi02B/xSuXeTNzEs6o0 kGmboRwwtT1re86BZq5FVAZSzsCae7uUZ2fd3TDTOpl1x1Tm3FmVJn28M6e1rj2nudye186O hlAGUsNAKDW30bsoA8qAMqAMKAPKgDKQ2Qyo0pTZ9ae5VwaUAWVAGVAGlIEUMaBKU4qI1tso A7nCALeg4FeZqRLuhk9YWbEyZrd+aioDyoAy0BYMqNLUFixqGsqAMlDPwEbYE2w+PipIlvAc xC+/8xWja27luYj+MT3vfmhkK1zjFhgqyoAyoAwkgwHdciAZrGqaykCOMsAvLbkFRd/eyVuE /szD/leec3413nmHc7BNRzscWH3On43cdCXPO0zevXO0WrXYyoAyEGVAR5pS3BS4oeWBxxt5 4lkjO+1nZOgwI6M/j00njHrNyO+PNrLJjkbOutgIpzooN/2Vv6CNHHeGf9TJ2dhbqakpkOkz jPzxXD/coScaGTvRT+PTr4yc9xcjJXcZGbKrkdPON9iB3Mg+RxjZFPcb+VwsH0FamB7z3GeI kRPPNjL7Fz/cz7OMHHYS9ooabLAhppEJk1p3n+A91Z6ZDHCfsU2xbcUZF2KbiqFGDjjOCHeS p9x+t5FHnzRy8jncFNLfMPWqm/3RIT4LDz/hh2O73vtwI6+/a2TXA4wM3tnIsy/713hQNDdy nfSjyBEnc3NWPhtQlE5hO+deYyKV2I4jKNye47LrjGy4lZHdD/bT5XVO6V15k/+c8Agh5onC +++F+z/zkh+ecb4da4TP3KDt/eeGm7WqKAPKgDKQswyk6oDTz772D9i96mbXzJrjmstvcM1W u/uHi/48yzXDDnLNV9+5ZvYvrtl8F9eM/ty/tsM+rtlpP9d88a1rnnzBP/SWh/jGi4u3+X5H u+apUa5ZsMg15/3FNRde5Ye741+u6bGpax4Z6Zr3PvbzsduB/j144C7t8VK20DX9t3bNyOdc M2Mm0j7KNQzLg4OHDnPNC6+6ZvES11xR4prdD275feLv2xZu1mmuNuhUtef4err+dtf0HOya /z7lms+/cc0Wu7nmutv8dsG2zTbz13tdM3+Ba+552D/kefZc17z+rn/oNNvv9Bl+2zz7Mtfw gOdTznXNnofG2hbbc/kq15x5kWv+cqNr2Eaff8U1POiabTRejj/TNWdd7HrP2y1/d82mO/lh eEA202J8Pg8d++O5Q154f/LHZ4eHZe/8e9d0HeSaJ571D9LmNYZLteRye87V51jLrQykLQOp 6mTYUbDzsMJOgS9rylTY7Uu/tMxXpt4fjU03V7umfT/XTJnmh6ut9V/qS5a6Zs6vrpk81UdF pWtWlrvm06/8cFVVrrn4Gr9jYvrHneEadhoUKj0s8ydf+G4qP1S24uWCK11z0dUx/0++9Du4 x59xzbmXx/y/G+d3lozfkvvE37ct3LncyaSqPcfX00HHu6bkrli74I8CKj01Na7pPNA1734Y u/bxZ66pRJulovTBJ67ptZl/jQrQ9nu7pq7Od7Nt7n+sb6cC9NjTvp3t9e33fft/RvhKVHx+ +KNjwDau4TNDoYLPHw9UlDbd0TXV1b4/r1GZ4vPG+2873M8X/Y89PfYM8Llpt4FrFiGdVEsu t+e07Tg0YznHgK5pSnGV8+iJow+N3ZRnufXp6bsX4wiTe/4j8vX3mNro65//xnPcJk3lrt8i m2/qr9WYMUukRzfuBu5402YTJ/vxf/xKvPUkb78v3tReCJOvVVUiV13sX+cRJ1dd4tunTONZ cSJ77OqnyemOoZv51+x/dAry+jsizz1qfRB+F8ebvthiN5GnkVcr5ShH396+q7n3sWmomfkM 8IDmEffHyuGgebHtTv3Jb7P77+23N+hJwnZ87W0iv5b6O9tvtYUfj2kcsLeI3YGeO89vtol/ jc/PlWjPbJsTEM6ec+gdF7RV7L7W9srbIsccJhIO+/ft1tXxnofrbjNy7OGx3e+Z3qoKvw1/ 9JkIjwyyu9dPxrPy5/P9FPnc8NnrjnRUlAFlIPcY0DVNKa5zvtx5UK6VZ18SOQgv6NIyrleC soNz2n4eI/K3m0XW7+O/nKmE7LCNjSHe2g3bWXz+Fg7RRedDDNjQgbKEDgK1+s17IhM+Yafg dyxLl2FtCY4ysYrROKQZPJOusTPqVqzEgb2Isz6UKytcZ7JoiX/Ab++ossdrL74hcvapIi25 j01bzcxmYNYcfvpPpSKmGL3+rsiZWHtEZSd4EPWIZ0WeeE5kJM4wnDPBkX3wBdw2Q/3ys21u H2jvbP/b4hrb1vyFOPNwsN/+iotiR/hQ0bLPRJBFKlx8jqyMmcBDs7H+CWn27mV9RT6GojRk U/8MyOD9uX3BL7+KbDXED8u8NHafWEpqUwaUgWxmAN2rSqoY4CJwvsR5WC5l6k9GXnhV5PQT RV5+U2S3nUT2G+54B+lS+dk60IkEFRy+uG0HlJ/vQDHyMX8BFpV/IXLdn3kmnCOX3ygydx4O 3MULn3GoMDE8hR1D8OXvdUz4pc6F52+/b5AHfAUFhYtfQk3DKAGFC8VfQT7bt2M6IvzVTWEn xF/np/0h8fv4MfV/NjEwBovAqyNQgvBVG0eS7n1EZMdtRQb2d37T3p56QeT8s0QGDXSgsBh5 4LFYewy2b/LDtrot2ib9h0BhYnsPtt9IxHgjWVtHR6q+GYNRrJnGo7ZzR7TfGf7I1K+lBgvU RdbrgsOj0YY5+sURJrb5f0B5s6NJ9llgAhzN4nmMxfg6j0JlK/gsep76TxlQBnKGAVWaUljV /DXcD6M23Edml/2NHH4SpuPuxK/YLRzZaTuRr74T2fdIjDidKXLo/iJjxlPpMV5nYZUkZpe/ 2oMKjy0CD85lp7L7ISJ7Hmq86bIO7UVefRtxcO9gnOAvf96jHFMTnAKZOEW8+/OYW3YUl52L r5Qw+sWvm56Hgvd3jIC1b+fIhejwDoWyxy/vDsNIwr9u88Mneh+bZzWzhwGOVu6/N6ZwD4Zy sytGH18Xue06v3yeIrJlrKx7Y2TpyhL8SDgKX6m9zGlitFOMms6ZazAtJ9K/n6+k8CBpTluz XXttK/pDIpgep8823ACKUHs/zqnni3wPBY5y0dl+PrbcHdN0p2ME9yYqTY5c8CcRjvJuj/xu MxxAugfs48Tuv4GfllXYvMTwL6hQWT81lQFlIHcY8N8MuVPeJkvKRZar5yWXjnsfwSf+6Fge /Tc7B06nxdZNMGP8VHoJOoh+6/v5WLgYn/N3b36eOPLTv5+/joPTC0WFHDFqfjqWrCVLjTey 1KljwzTmzffXgWw8MLZmxMZJBzOXDzhNRXtuqo45Srl0WawdNxWOI6NU6jt2cKS21sjKcn+d XlPhW+pfXY3nCvmJ3zuKI7+z5nAkLKZwtfQeqYiXy+05FfzqPZSBRBho2AsmEiNLw6Sik+He NTtuJ3Lu6Up7KppRLncyqWjPqahDvUeMgVxuzzEW1KYMrFsG8tbt7XPr7sN+J7LXsNwqs5ZW GVAGlAFlQBnIFgZUaUphTZ5xko4wpZBuvZUyoAwoA8qAMtCmDGDJpYoyoAwoA8qAMqAMKAPK wNoYUKVpbQzpdWVAGVAGlAFlQBlQBsCAKk3aDJQBZUAZUAaUAWVAGUiAAVWaEiBJgygDyoAy oAwoA8qAMqBKk7YBZUAZUAaUAWVAGVAGEmBAv55LgCQNkjwGuMHgvPk4ew9Ygc0NeWhqBbCq ElglZsVKJ7JyldQyB8WFEioqknBxkcnD8S4hHvHCo1569sAO0tgRmrtC98F5Yvag1eTlWlNW BhpnQNtz47xkqW9jn0M35pelxU/LYvnnJzXMWmN+DUM0w6VKUzPI0qDNZ4DHYPw0U2QGztyb MVvqsAPzahyAWltaJiEc/FtYVydOcbEsKcyXeTgGbIXrysraOrMCZ5gtw+GvyxzHrAJWinHC xpFCcaWQZl4oVJhX4LbPD0tRUWFoIM4626gqIn0i1dKuZ3ezut8GTh1yi1PGVJSBtmNA23Pb cZmBKVEhskpRvN0Wx163bjVTy0BQQbJ2mo3ZW5QzVZpaRJtGCjJQV4cDUmeJTPqRh6M67qQf TeWP053a2XNNMZSc2uJ28osRZ8ryFe44qTOlJmTmGdedF6mqnCfL11u+KphYgvZIk+HmFs9z e/YvXRDq74pZ3GQwvaAMNMGAtucmiMld76CCxCUtdFvT2slOMBzdKqlnIKggubi9dVs7TdaT 9W92DhlZBQzosROJNQOehzdxsq8g4YDWinETpHbWXJzhWyRL8gtkYnm5M6YqUjfVuGZ67erV 06W805LEUtZQbcmAtufE2NT2nBhPORzKKkI0qShZhKN2mvaaDQsvz4+mSmoYoBJEscqQVZI4 40C7NWm312xYeCUuOtKUOFc5F3I2xofGTxIZO9Gp/eo7UzFxiuTXRLzGtyyC6bO6Ovf+OuNO qAktnlTxU1+sQlJRBtKXgabac3GR/IRDfb+tWG3G1LnuRG3P6VuH6yBnVhGiskQFyWI57Lym kv4MUDniUg0qTgSFihPFKlu+K4H/qjQlQFK2B8F6IJn+s3gK0pjxTuSr76Vy8lRTHApJBRZb /1C+0v00UmfGRKoiY2Vpu7kiL4QL+x7zP8c4g2rKCh7Jdn60fJnFQHPb87LMKp7mNnUMWKXI KkzsL4l8wDFYhKmS/gzgwyDWIz4bkhrA1ikzTgWK7mZVpCpNpC6HJBIxMmWaryB9P16qvv5e qqEwtSsqlCV5eTJ+2Qr3U2PcMdWyeqyUdmpiTdBxddXlK48v6tBhTEHv2u8jZXkv5hCFWtQ0 YqBt2nMaFUizkk4MsEMNTsexv8T3ul4HnE751LysnYEiBLEKE5UkCztVt/YUoiFUaQpQVb7K SMcOltfAhQy1Llnqrz+agDVI3413Vo0Zb9xfS6Vdh/YyD6X8ftkK83mduGNra5aPK5/TAx/8 N0OwVqmuKHJEOD/vg4Le1T9GygpxF5V0YkDbczrVhuYlQxmwihOn5TjCxBELdsAqmcWArTMq S3Zdk52ia1ZJVGmK0tWrh3ls/aHOSVtvYaqOPNjpeOC+JrT5ppmhQHFvmB+ni0wFpkx3asZO NJVYrJ1XUSnhjh1kWnWV81XFqrrv6sLu+JrSOZMrZJPqZrWSJgLXLCoYj/HO7k1cVu91yIC2 53VIvt46WxiIV5ioNHGkqThbCphD5WCdUUnilFxQaWq24pQZWkGqarZvabvCup57d+wcPsK4 clhRkWl36P5OCApU8eCNRQYNwIR23rqhrKbGCPY3ktlYUTQHwOf9kfGTnMppM0w+NoUs6Nje meOImbRspfne1JofHKdmYlVZ8exUUaf3SUMGtD2nYaVoljKIATu6REWJIxXtougA8xtd0wQW MkCimx3vjKxydxt+sERUAdy5huuc7OJwWNcu60YDWHu+0iJEQZ/qzcNO3sFd1nMOrq2RzSor pfv6faVyy80d2WZL6TBksAltOkgwpYel+Z1FOnXEpKm35izx7HPR6hKsRF2yVGQxgQ/0aS9b KC5GjyqxMWTtr6VO3vLlprh9O1mKz/p/wT4y05Yvl3GYlv3RMTVTqhYUzcadm7WYLfEcJhLS OPm96/4YFvNLVVn+6ERiaJjUM5Bu7bldsSytrhGnoEC+XlVuPkmf9pz6utE7ph0D7But0sQp OY5UUGnCW94D1n6uw1cuMqGSGAPRPnkPhOYSFIJK02qAMy5WaUq4MlVpAmuJy0+F+T36b+7k h4YU5jlbYv3TTtjBemBtnXTEDtYdamqkEB1BNdYM1XTuJC6UKDeCTqEWh4DU1TlSU2scmlB6 HOhKsnKlFFSulgJ8oVZZkC8rsBB7KSpkIXbELquoCM2srambhY4EqJ1dVfbGXJHjmqURJ16u NgjZu7xHUaj9WFfcCyKlea+1QYqaRNIZWLftuajP0beiiOtXzQ+fkvSi6g2UgeYxwL6Ry1c4 JWdHmdrDTqWJn6+/r0oTWMgAiSpN+yGr3CaCSlMFYEebqDTxmC5VmkDCOpCSkHS6tEthUeF6 bji0Hs796FALHQl/tU7I1OI7jFqnLmrWmtrq/MgyKf0nxpVKmj2vug4Kt9Zb5veJ7BCWvHdc p2b3SGnh1LVG0ABpzkDy2nNhj6pNnPyCr6pqKofKog5laU6EZi/3GLBKk13DxFEmTsthTsFT mt5WpSkzGkVUaToIuaXStAKw03QcbeIUnSpNIEFlHTFQ1Lv2NBMKXVMdWbK9LG7mF3nrKM96 29QzUNjHfQc/7t6vnh/+Z+rvrndUBtbKQLzSRIWJo0xUmtYDXlelCSxkgESVpsOQ1WUAlSaO NlFxapHSxD0oVJSBNmOgqixvhEQihxSEOw1os0Q1oaxioKjX6oGYoB5ZPT90d1YVTAuTjQxQ ebII7tmUjWXN5jJxfZqtP1ufNJstnLNVUQbalIHqxUXY/EBFGWicgaoFxVinJ4SKMpAJDAQ7 WdvxZkK+NY8xBmy9BesydrUZNiakogwkgYHv8/N7R3aUzss5lK2iDCgDykAmMRDsXOPt2m9m Uk36eWWdxddj0J1wibTyE6ZKAzaPgR1q8D1CuKhdp+lY9Ltx8+Jq6KxkoHtF36I+7ufSc1Wv rCyfFkoZUAayngFVmrK+itddAWsWFHxtxFwneQWvSa8yfq6rksMMFOYXP+CKeUsWdliQwzRo 0ZUBZSCDGVClKYMrLxOyjq+j/mMc83VRuOfjmZBfzWNyGCjsU7M/BseHRuZP/Udy7qCpKgPK gDKQfAZUaUo+xzl/h0jpS2cb13yc16dm95wnIycJmFwgTvg+MXUXiGzBfVFUlAFlQBnISAb0 67mMrLZMy/RxddVl8mCm5Vrz2zYMFPYc1M81tSfUzC/4vm1S1FSUAWVAGVg3DKjStG5417sq AznDQPXCop9zprBaUGVAGchqBnR6LqurN/0KV9i77jx8QfUdtunheU4qyoAyoAwoA8pAxjCg SlPGVFV2ZLS6LPwAjs+YWtRnw0ezo0RaiqYYwBq2PXBcyg8iP/GUeBVlQBlQBjKeAVWaMr4K M68AVfN/+ZNxnCGFfeouzbzca44TY+DjvLCEH8JxKdeJbFKdWBwNpQwoA8pAejOgSlN610+W 5m5gVXVt5YHYoHW//L6R7bK0kDldrMI+e1wEAuZESvNey2kitPDKgDKQVQzoQvCsqs4MKgw2 OMTww0EZlGPNaqIM9FjVGyeLX2NqIrskGkXDKQPKgDKQCQzoSFMm1JLmURnIJAbcULiqtnKL 6kVFP2VStjWvykAmMXDyySdLQUGBdOjQQdq3by/rr7++XHLJJbJixYo2LcY999wj+BEkn332 WZumm6mJqdKUqTWXRfku6Ft3pa5vyqIKXdJunh6VkkX1qUVJWwYuv/xyWbVqlVRUVMjkyZPl 7bfflscfb9vDF5566inZaaed5Nlnn01bHlKZMVWaUsm23qtRBiKy4F78lDkd2xGc32gA9cwc BtZb2lkEO4CrKAPKQEoZ6NKli5xwwgny8ccfe/ctLS313ByB+v3vfy8ffvih5z9x4kQ5/fTT 5a677pKNNtpItt9+e5kwYUKjeZ02bZrMmzdP7r77bhk1apTU1tbWhzvwwANl5MiRsvPOO3tK 1ejRo+W8886TDTbYQI466iiprKysD5tNFlWasqk2M7UspX0rnbrqwzEEXJLXt2a3TC1Grueb Sm9hcZdX9KiUXG8JWv51wQAVn+eff16ozFDuu+8+6dOnj4wdO1ZOOeUUueCCC8QY441KcfSI StW7774r/fv3l+uuw0eujcjTTz8txx13nOyyyy5SXFwsH3zwQX2oH374QR5++GH517/+Jdtu u63su+++Xpg333xTqGwxLyrKgDKQRG1SeegAACAASURBVAYK+9b8HhtfzpfuFX2TeBtNOhkM 9F3ZHXW3qKB39ZBkJK9pKgMpZoADChwx7Qj0AgYB2wJ7AccA0D/WrZx00kmG+bAIhUJmv/32 M8uXL/cy9vnnn5vy8nLjuq4ZN26cF27lypXmyy+/NN26dTMYNfLCffHFF2aTTTZptDADBw40 33zzjXft4osvNlC+6sNhBMtA6fLcWO9ksL7Kux89sLbKXHXVVfVh16Ulyg/rjHXHOmRdsk5Z t6zjZg0e6ddzYEwlPRioLs1/T+T7DUW6hdMjR5qLRBkoNO3vMGKejJQVTkk0joZTBpSB1jHA hd92lIiLwYuKYgctcCrtiCOOEChMMnTo0AY36tWrl4TD/muWC8lXr17d4DodUKZk1qxZcs45 53gLwZcsWSLLli2Tqqqq+vtwKo7CBekbbrihtyid7ry8PKmpqaE160SVpqyr0kwv0A580rLz acv0qmki//m9Izs64hxSVbNk0yaCqLcyoAwkgQFOmWHU6Dcp19XVyYknnih33HGHvPfeexKJ RLypMxsQo1LW2qTJKbzTTjtNzjrrrPowGN3yFptzzRIlkXTqI2eJRZWmLKnI7CrG9/lFvbc5 yTV1YyILCnEMh0o6M1BTtmBSjczoh9Hv2CrRdM6w5k0ZyHIGOCLEkaFDDjnEU2yefPLJZpWY StYLL7zgrXnacccd6+MeeeSR3ld0Vmmqv5BDlrWrmzlEhhY1XRjYocbU1X4RCuV/lN8rsnO6 5Erz0RQD/TC2rwpTU+yovzKQaga6d+/ujRJxgTYxfvx4ofLDLQoSkXfeeUc6d+7sxQmGp9L0 1ltvCdZKBb1zyu7kVGm1sBnFQGGv2kOccOghbJS4ve77k45V90K4oOfhW0QWLvxJhIqTijKQ NQxwQIEzMTxsuh3QAegEdAE4HzYKi5thpLfMnz/f2/iyU6dOwik7LBJvdDovvUvRutxxY07I scASYDmwElgFcE8EnovJEXIXSEh0pCkhmjTQumCgekHem/jw45GicLsXsUA8f13kQe/ZNAOF fY++x8nLO1sVpqY50ivKwLpkgFsOUGGicOF3Y+uf1mX+MvHeuqYpE2sth/IcKQvfhIXG7xT0 2nJwZIFMyqGip3VR83tEtnGMc3RV5crN0zqjmjllQBlQBtqQAVWa2pBMTSo5DNSUFXybnJQ1 1ZYyEM7Pux8j2tfJii7LWpqGxlMGlAFlINMY0Om5TKuxnM3vT4UFvaqx2cjc4pylIE0KXtC7 9jis5qisKs17NE2ypNlQBpQBZSAlDKjSlBKa9SatZ2CTagmFNynqu/40we7TrU9PU2gpA5Gy vBeqS0P7tTS+xlMGlIHUMHDyySd7G09yA0tufslz6Lgh5ooVK7wM/O53v/M2pORaJ6596tu3 r/eFHReNc8PLwYMHC3YCb5DZ/fff3zvTroGnOpQBZSA9GSjqU3crjusYLfKC7hqenlWkuVIG soEBDiik9TEqiRxNwqNWrr766vqg2L/JOzIFB/B6fjhs12APp/rr2JrAOw7FHo/y9ddfm/z8 fINDgL0w//nPfwwWlxvsAVUfJ90tqEd+5ngM0CbHqOhIE5hUyRwGqubfcgOegKrCPkf/NXNy nSU57b6oY2Hv2oNFJrMzUVEGlIEMY6BLly7eKBGUoEZzvvnmmwv3eIp+pi9QquQvf/mLnH76 6TJp0iRvFOrRRx+Vrl27Nho/FzxVacqFWs6qMpa41fPnHYktUpbn941sl1VFS/PCFBZ0e03E GSCyRSTNs6rZUwaUgUYYmDBhgjz//PNy4IEH1l/FYbsyYsQIwSiS8JgUnie3114clPHlxhtv 9Da6pAJ1/PHHy0EHHWQv5aSpSlNOVnumF7rfamxFcEtNacHYTC9JpuSfi7+R167VZS89lCl5 1nwqA8qAeOfPceSI2G677byDdU844YR6aiZOnCj/+9//5KOPPvIO6OUGmD///HP9dR7Gu+++ +0plZaUcfDAGmlWUAWVAGVAG1sBAr7L2RX3duXl9a3ZbQyi9pAxkEwNZs6YJC7/N4sWLPWBx d4MlSPFrmniR4c8///z6cFCqDA4GNn/605/MgAEDTEVFRf21TLCgUeqapmx6MrUsrWOgoHfd jYV93JfwXOiRQK2jssnYheEep4Pfx2pL879oMpBeUAaUgbRkAAqPtxM4v5ArKipaax6HDBki nMaj8Cu6M888U8477zx58MEHvWm6G264Ya1pZHMAnZ7L5trNgbJFyl66VRzpgi/qbs+B4q6T IlaXhu+rKg3fuE5unv43nYgsnhjN5miYcwCeVWaFZ5fxly63ybgN+ASIl2fg8VTU06Z3Bdxc O0bURWHdrIvDAKYbDz0DEKSoJM5AdXW1N/WGESR55ZVXBF/W1a9b+te//iULFy6Um266yTuG 5YEHHpB77rlHxo7VlRGJM6whlYF0Y6Djym5QmmZj3Q0/K1VRBlLJgFVyeM/RAHdIp3JkJag0 YXNWTwHqaS/C5JeI3DTHrq4NpmeD3QNL/EaiVJom2QBqtjkDWTM9F9xyIH46jdNzYK4e/fr1 MxdddJGpqqoyM2bMMO3atTNvvPFGg2hnnHGGwdooU1tb28A/XR3R8rXZlgN6jEqbP2uaYMoZ KO+0xBRW7R/KL3i0qFfV2KoFRTNTnocsvGFhz6pBbihvWE1ZeCS+muOLVWXtDHArjL8AI4Cf gKBQyZkCHAE8HL2wD8wa4P2oWw1loM0YeOopO4DZeJLYh6nxC/AdNGiQcPQpXv773//Ge+WU W5WmnKru7C1s9eKiaSjd7tlbwlSXbFaREy74IOzWnVmjClNzyJ+LwH8H7gUOaCQip+KOBqzS dBTsLwJUnJornRHhD3GRqKiNifNTpzKgDLQRA6o0tRGRmowykE0MFPXd8CqM2n9btSD/o2wq V4rK8g/c5wzgSODtuHs+B/dNwHrASuBw4FigJcI0zo6L+CrcqjTFkaJOZaCtGFClqa2Y1HTS hIGSUFHf6290XTOZZ6SlSaYyKhtFvVcPwHTchVjXsHVGZTx9MluNrFwM3A+MBoIyCw4qNYcC XDTOsJ8CLZHZiLR3SyJqHGVAGWgZA6GWRdNYykC6MlDiVtVV3h8Khf5R2KuWi2VVmsmAGyo4 zjXuWbK03a/NjKrBYwy8BSvXMF0T86q3PQsbp+g4EvU8oOvFQIKKMpAJDOhIUybUkuaxeQws 6LiwrnfkqHAo7+3C7lXDouudmpdGDoeOlIa5mFml9QxcgiTGNZIMR0BvB1YArVHseWh1VyBe lsFDFbF4VtStDLQBA6o0tQGJmkT6MVBTVvBduFftlVJQ8Jp0X7SjLO5Rnn651BxlOQMzUD5u FxA/2lQGP3621A9ozfqjzRB/CRAvneHB9VIqTTBQ0l56S0g+dHzl0oWGabDfm4vgbr2fERxx CQ//09EQAjlLXJn4n0rhKKJKjjKA9qGiDGQxAz0WdpDavLAs68pf9SprYKCwb81+OKGqf1Vp XvyeQGuIpZeUgcxkoKSjfIHj2HZNNPcr6+SN+yvkniqRLogzCvsSJRpVw61DBnjmHoQfW/AH xnKAPyhWAZUA1xTWAlSYExIdaUqIJg2UsQws6smHQ2VtDHSt3MCR8HPiVm+/tqB6XRnIEgae QDkSUpqW12Gj7Ap5EuGpMKnkMAO6EDyHKz93ij63OL9P7R+layWnQ1QaYaCoqPAfmKG4t6qs eHYjl9VLGcg+BsrlBUzKRYCmh4yMVC+plXOhMPFLSBVlALO6KspA1jPQb7WpMzOKCovGcpfr rC9uMwtY1LtmL5x3vHNV6S93NjOqBlcGMpKBG9rLftJRnkbm87GWqallKksXu3LYPZXySkYW UjOdFAZ0ei4ptGqi6cZA7cL8r8J96q6XMBaG9yrbWRb0rki3PK6b/JSE3FBoR3FrDhYZiOUa OScFKHEkiaXmF26UOt9Y43/mhUo92+avQMLrLBBWZS0MnA0Faf2OcjKC/Rlq0hZecIwkweT5 gL5w1AlKFIaeZmDR9+H3VshcXGhnL6upDOhIU+JtYDCCchg3H+gRtT8IMyh8ID+KekyHeUHw IuxFAL/i4mfGwfS+gZsvboL34JEK1s1DPp+K+vNaECPhVkmQger54YeMY74tCvd4LMEoORCs xOUWA5GywskZWFgqFlu2It/9EffnVsQPRr0bjluiHgfBHBK180iVa6P2poytcOFVYARwEnAz 8CNwExDr0OGIyokwL7aOqLkpzH8D3IH8L8Da3u3/QZitASu8D98zQexqL8aZZ8D9BsA9po4A +E5ck5yGi8zbOpESKD0lneSi9Tuhrh15zFOYjMzDm/SaciMbYj33Qi9jUYUJ/l/Af5d7V8mM dZJhvWlaM7C2ByutM58GmTsWeWhq4eyzuHZUXB73g5sK0btx/jvDzV+ZRBmAX/31bm6QRykB OIwcxClwqzSDgUjpLWcZcf9b0Lean2urZDYD7NSnpUkRqDD9M5qXs2D+LsF87YNwNwJ/Ahjv LeAcYDhAxelfgBUqYlTAuI3BJtYTZgfgdSAM8PruwJ1AY3IoPB8GMPDSYFHzRnDzB9pzAcyB PV6Ohwfz+xJwH0DFjkpUU8J8Yr2cN4LWVJik+JeAF3whd5XTUWbjpUmlrR8UJL5PTzblMuDG crnj76ugMBnhu5pvVo4wPbu4XPb5R7ks9fz0nzIQx0BenFudzWPgZgS/H9gFwPPWQPgg8gXW A1gUvUIl6mUgEnU3x4hPvzlxNWw9AyVudWnJe/XOHLYU9qm7xBWzpGZ+3pNpTsMeyN/VwA7A xwA7/OUAlYc/A32AYwBOgR0H/ASwI58NUDj6chkwFTgEKAH4PD0NWOkOy23AYUApcB7AEWDG ozKyI8AfSP8B5gIlAKczzwS+BzjKzE+Yi4G9gO2AJQCF7wCui6EixfyfDlQDfP/eAfwe4D0+ BUYAzANHcKgkUYEqAnivAQDzORsIyv5wkI8Lop5UUvieuQpwo37W2BKWCqDcekTNQTC/A96M 84937gcPjqqNiF54FCY5Jy/xwvJRQXsQ2Cb+YrLcJRhZgqJ0ISr4cnxtTr5Y29/AfXtJuTdC xrqPiSsjMS53MTxvK1kp1+MCr4diAdSmDMQY0IYR46IltkcQKR/gSzBepsLjB+Dw6AW+QA4F no26m2vwZfeHOPBlrNIiBmYVFfVaPRB9GOtFuEdRUV/3ixYllSGRCvu4L6GMXoeR17dmN+xf 8ucadzE713SXe5HBvwM7AXxnnQ9QdgDaAV2BCwEqDsOA6cCtgBUqHFQeGI7PH0dTLgdOBaxQ OaHSsxXwGMDOntIPuAYgT38G7gR4/z8CnwM3AxS0JekPPA18CzwEfARQeJ8XgWMA5vlYgLIp MA1gvvlsvw7cB/wKUGFjXS0FmG/K28ClwMd0BGRj2McH3D/DzjjdA37WejssTIPpBoVpUHH6 DGD+LcewNpAb4OJ7z8rusDBOY3IdPJlnljHpggZQeFMnuRgK00yMGt1JhQkjS5/X1cm+GFX6 HRQm8ktOG0hJpYxFuEOhMDG/v7neILA6cp6BvJxnoHUE1CE6f929CvCXZLzwBX0UwF9jewAR IP6FB6+EZHuE6hYXksP3i+L81JkQAwOrTLju0MK+e55RXTp3F8d1NkB3vKt0r+gji9vPTyiJ zAvkeFnuuqRTWML3u6775wxYEM8fJT2BwcCnwBlAJyBeyuBxK8BOj8rNLIAKlgvwGaRQafkO oAJG4YjJbZ5NZH2YvaP2+2EGn9OX4KaiRVkAcOSEikUYeBIICpURjuQsBMqjF0bBpDJFeRfY zLOJUFGZHbVTkWK+KTsB7wCsr44AR77WJANwcWUgwDzYyUP7gN/arFT6CgAqRczfLQBHw/ju CorNSzt4/hPYGbD5Doaj/34A33snBi+0tR3EhYd2lNPA1o1Iu5/HGkeWXLmupEI+SOR+UKje TCSchlEG+FJRaR0DXyE6X4R8YccLX7R7A50BvrhfAPgSb4mMQCSmFcSEliSkcXwGqkvD9zjG TCrq0/dhV5x+6GWqCvPa2Q42G2naGr+oVxUWdLkDhVsaKfvsZYw4DSvoVctRjnSVGmTsbMCO jvwb9vxGMjsDflQUKFRa+JxZ5YR+lL2ALzyb/+/rgJ3PL5WM+cBogEqElV+tBSZ/+EyJuvmj iYrG2iQYn3mjwkGhP5U1yjKAI0MbAMMAjhZdDXwCrE0qEaBbIBCnCMnb3IDf2qwXIwBHjT4C HgAeB5pSdrbAtckA77ktEH8f9itPAg8BWwMDAL4DaW9TKekgx0BhmgxF6VEk3A8tYAJHjbyR pQQVpjbNkCaW9QzkZX0JU1PAK3Ebvkj5yywov8DxHXAYcARwNKCSBgwU9q492EjdrKpVFZcU duzwPt7ymyNbRVgKehrM+9Mgi22cBUxDOl6nEsK03A5QKUxhnz2rHYzGuOI21Tm2cR5alByV ki+BTYCtgGuA24D4PHNExkpPWHoBZdYjas6EuWXAj2laoQJ0AEDF5XhgJNAfoLT0h44fu+nt BiYhAPPTCbgVYLlmAGcCbINU6hobxYF3A5kD1zYBnwGwTwdqA35rsw5HAP4IWxYNOAumLX/U yzM2xv/Xgb8AnHJsTMLwXAVQ0aWsB3QF7gX2AFot2Gdpn3DYWw+2o5eYkZ+gLN1Qssr7os+0 +gaagDLQBAP8RaDSegb4cuZLj1N18fIsPG4EqFBxnUJLhb9O+eIJIthRtDTd3IwXCp0dCuVP LurYYREI2AwKxfYkwjjoxPquZMeZVVLQe9fB+BVehXUeYZRxW0xc7Ywy19S57umRBXlso+kq VCjGARypmAg8D/AZiBeOfhCUPwI/AkvpgJwAdAPeAPYBBgH8wUjlyMoTsBwELAQeB6hwFAEt ESpgHO1Zm0QQ4K/ACIAKHZU2vkNGAzsDYwE7EgVrk8Jy7QpsCvA9cRVARZPC+Ed6tjX/OxaX /x0NwvZ/MvBS1L0LzB2i9mthsg7eBngvwvJkw3GUa7sAroH9M6DVClNJO9kB2we8D4XpA6S3 IxSlUqi05+BruCFQmJ6DnypMIEEleQzwxaHSNgzci2TOAvDjvYGMgosvo7sa+DbfcSWiEEH5 Hxx80ao0k4Hq0tDhRb1qzzSh0D9RYwX10Y3UFDntjqj67VqO+iAZaQmFt0J3EuxQlrqmdv+a soLv07w8i5G/t4BS4BuAHfolQLzMhscLAEc52ImfBFh5BhZ26F8Do4EfAabHjt/KPbDwWZ0A 8MfIwwDv3RJ5H5HuBMoSiMx7LgK4LpKK03RgA2AA8C4wF1ibzEKAK4AxwCqA9x0OULYH/gO8 Qsca5B+4RiWJ5d8Y+ASgMkY5H1gBsK2Qx8HA1YAVKne8TzCcvdYmJrYO2Awv1lvxrB7NBNGQ l+PfXSvK5d93i6xuk5toIspAAgzEd/AJRNEgykDaMNBY+23Mr+kMd57TuaB4/b87odAJeAkX YiQmBPPzqvmhPZuOlHlXCnvX3CVO+DLkHPqgTKuuW3SgLOzFzrqtJaiY2bQb87PXEjUHICBH b6jwxMth8KAitS8wAJgFrOmeDMOOdgEQlPXgGABMAaqB1kgHROY9OOqUqHAEbSOAypMdJUs0 LsNR2esBMH5LZUNEZBtZ2NIE2jLetUXSPz9fbsBDfSoUpjAqtRI1e09VufwVWumytrxXXFqc heGgQiHA0TTWZyegC9ANGGUwzKWS/gxgOQIzyZHUJcByYCXAHxeVAJ9zjiq7QELCRqGiDGQK A2z93hMQNYN2WwbrZ91rNlf0r4iskHPze89/KOT0fMwYZyCesWHS8Y2uUn4oH66sECfk7I5X fJ1xa5+LlJ10Ad757MyT8fwHexJrp9mYvTnczk4gMF98iSgMTaXFTritOmK+lJsrVJRaoizZ +5TDQrRGfmlN5LaKi2m4vmid16LVnIXnsQBmDRrQI5Faufn2Sm+xflvdqql0bJttzEy4g20q cfVPOQOss8bq0volnKFkvDQTvrkGVAYSZCCoLPEXIN3WtHYmFQxHd8JSU9ZnKmZ+di3sOfVk yev6QF7BRlvj58e3CSeQ5gGNcauNWXl9pKzrA8gqn/tkPfvBl1DwRWXtNFlPwXBwtkqmIfYT rUpBI6cFA9e0l14FIW+q8Tw0kiI0EhcDOk/VRqTk1uo2O/KmuWW1bZUm2y+hklkM2HoL1mWL SsCXl4oykM4MsI1aUFGy4NoV2mnyelCJgtPzo9l8KTqxvVQ9U9H8iDkdgy8jin0p8SVFO0e0 aLdmm728kKZKljDgjSxBWcKo0tl4covRcnhw7os1rtx466pGp2STXXK+U/jDogDgtDCn5zj9 2RngNO7rOj0HFjJAotNzhyGrHEXm2jyOxnIkmNPnEYDTc/b9BeuaJVm/Ntd81+RcZeMmAckS ds6URNYoMC+DAHa8vwLsKFRaxkBQYWIdWHBumtfaXqqeafs0cztFvpC4FoTPjn1+7DOR8Msq tynMztKXFMkAqCWXo8s6EwpTkacsGXml1pWbbqnwFqWnS8Gt4s/263Wy6IyT8/5JlxJnTz74 jmGd2fePffe0qITpojRRsTgQ+KFFpfD3E/kccfu1MH4w2t1wUAu9HjgImA1wYejfAWqqNwNN yVa4wOtcYDYT2ADYBXgOuB1o7eJSJJFTYl9KdkSJ7ZXIB7Avpfa3mdAaop0LF9TyU3Rbp8w6 X2J0a0WSjRySkvbYVyqMkSXjnVvHH0JsA6OgLN0CZaml/UAyGGS+2MlapYltmDge4KhTJ6A9 wMXiRQDfTXxH8Z2lkjoGWD9UjFg3/JCBfTAHLbgulaNLtt74zrH12aL3Dis3HWRXZIKfyaaD 3IJMWDLPgv1NgErT2mQfBDgP+BPAytoaGAdwKHdP4F/AuYBK4gywQ+XLJ6g0cRSPHbBKZjHA DsUqTHy+LPgCs89bZpVIc9ssBkqoTHSQIzA+cx5awl7RyDX47fM0WsBdOMokkfdss+7ZysDB NsrOlp0ywR+/7Jj5LqLCR2E75kyH9VOliaykTsg/64h1QHDqjf0wTdYV68zWn1WcbP3iUuKS aqVpD2TtamAH4GPgbIDTLPcAfwb6AMcALNRxwE/AGcBsgPI2cBmARbsZfVr5Dcj/4mgZtoH5 AnA5wErtC/wDIFeTgbuADwGOYl0KsOz/B3DUi9xMABqTm+DJX0NsMEz/doDyDvAswD1V2Ild AZBrzvl+C5wMVAJB4YuB8U8HZgMPACMAvhhuBpgPNsAHgdui9pbcB1F/I8wj78M88FdcIcAO WCWzGLB1xnbCF5xFZpVCc9tsBkqKMeKeL2djVOksvHH4jufLYhX+PYI33j9LVntLGJqdbpIj sJ1asK2yTyLYIbMDXg1Yhcn6U2HiO4r+fG+ppI4B1hXrgSNKrCP2e6wjqzixzuhv65F1auuX ZsKSaqXpXuSMSs9M4G8AO252slSi2gFdgQuBEmAYcDVwK8COnEIiWFiGY8d/E/AdwFEcK+fA wk6fSgaVgYcBjvr0A04DONrzDPAy8CXwR+BUgJ3/QcBAYBVwN3AI8DHwETAcYDjG51Td48Cx wFPApsA0gAogy/Q6cF/U/g1MAywFmO9SgOEvAw4HqDyNAnhvxrsAmA9sB+wHMJ0hQHuAPFBh OQC4EyA3hwLxsi08DgSOAthIPgTeAqhgbQl0BC4BTgM+AP4NsKxPA8cDLFtQWCbeczdgEEDu Pgfotz+wM8D6exX4FRgBtOQ+iNZA4hWmfFwtAIobhFJHJjDAOuOzy/ZIMwg4VbKMAQdTcPvh 5865eIj5jgp7aoTBD0GDH1er5MmShocMp2vx+e627ZadLhWivChgeO2Z/uyg+W7iNf7II1RS x4B9n9TilqwPwipO1AdoDypODM+6bbawglMl7PB6AoOBT4EzgE5AvJTB41aABeLo0yyADZCF pBJAOQb4DqDyQqGCc5tny5zTyp9Afj+J5pkK0MEAlSar3FBDngRsBnQAKCuAywB2PCz7CICy OVDk2fw4DHciMAPoCswDtgeoNFFuAb4C+AI4DbgRWAW8B1ChixfW1V8BjvwR5wB8QZwFUOGa C1DuB04ARgCU5t7Hj9Xwf1Bx4j0LAVvWhiHVlc4MsM74QmPbpclnmnWrkkUMlHSQoajVkzEF x/dPPxYN02/swEbhDf5gySrv3U/vTBD2QVZh4ggG2yzfmTQpbMfsiPleItif2us2DLxUUsCA VZrs+4VtjmD9WOWJbtYjwXAtUpxSqTQxo2cD/wTuAl4EbgbihR09GyuFigMLthkwBbCyFyxf WAfMrwN2KlyPA/OBz4G/ATbur7BbIYHWnwSy0a9NgvGZN46uUOh/hGfzp826w74BMAy4D7ga sAoSrJ78ZC0wZwFXRN15MDlisy1ApSkoC+BgXilUcvjrnfICMMSz+S8q/uq5AaCSuRyIVzJs OcjBLwDTovAlkO/ZGv4bAOePAa+RUTv9vwn4z4S9R8Dd3PsEonodKjtVgi8gvowI1hMVJ5XM YoB1Zl9itmOx9UvTPvOZVSrNrVzXUQbnGzkGZxoeB2VpqwAls1CrjwD/xXqlhQH/TLKyXbIP 4nuXfRjbKoV+fF+yU+Y7k7Dtmu8rGw5WlRQwYOspWFesL4J1ZN89dLdYYUJcTzOmmQphZ/cl sAnAB+sa4DbgRCAonDqy0hOWXkCZ9Yia7Jw5/WOFaVohIQcA3YHjAXbw/QEKCW2NWIUlPg0q N8wPR85uBViuGcCZAEdfqNRx1CwowXIyLhUiPnTPAFSyfg+QMypAVprKf5ALhuU06HoAeVkJ vAEEpal0gmGC9qlw9Al47Ac7/SYDGwBW+RwM+1eAlebex8azpu1UrdJEhZJQpckylDkm64xt mfVnOxdbv5lTCs0pGXBK2mHkOg9T+kaOhqLE0SVPS0DPtRTXX6jDhpS3lHvve3ZmmSq2I2Y7 5bufJoX+dBNsy7ZNa7sGGetI5rtopwAAIABJREFUWCe2vmzdUKmlnQqTVaCsH/smgnGaJazs VAkVirEAO/iJwPPA/wHxsgU8CHbIfwR+BPggUk4A3gOoBFwCDALmAFSOrDwBC5WGN4HHgeuA +JEWeCUkJNyO5qwpAivlr8AI4EyASpuVnWE5FVgfmA1Y4SgQR8GYt6OBzwEqOt0A5p0VyvK3 RDZDpOcAKkwDgd0Ajl41R3ZBYDa07wHyTeX2A6ArQI4HA8wn8/gpUA0cApD7thQHiVFpsopT PuyESmYxYOvNdiysT9atSgYwUMIlAh29s/0OQaUdhJrzf0T5NbgMU3CvwW9U6Up5/2H/vZEB pVprFtmhsoTBH3/0sx0uO2C25/g2zTg+M7CopIQB1ouFrR/23xbsy6ydpq1TxmmWpFJpWoyc vQWUApzS6Q5Q8YmX2fDgdBMbIhWKkwArHIVhZ/41MBqgQsX03gas3APLKGACwNEcPMNpeVr5 KuRrOkCljCM1dwGVwAhgHEBF8UvgO+DvwAggUbkPAR8CzgLYQEYC1wIvAYnK+Qi4AqDS9Djw DjAT4IviDqAceBJ4D5gBsDw0/wckQ6zSxHaRynabjLLkYpqsM9YdwbpUSWMGzsYPk74dZUd0 Q3tjJGlvZHVXqAGFNsvoaX6B/S23Tl4rq5CPskhRskW0pu1Ug52s7ZTtO4kKEu1BZUmVJstg akxbTzQJ1hFNqyBZ09adDYcgzZN1UbEDkEUqClR44uUweFCR2hcYAMwCWLimZAAurAYWxAXg iM0AgMoIR0BaIx0Qmfcg6YkKR2M2AmYCdpQsGPcpOL4ARgKdASp+QeGvuAqAI0XsZLoAS4Dm CDnuAfwSjdQTZmvXFfRDGsxrkAvmbxOAeY0vB7xaLGyb7Gj5omZZWA+dAPJFfl/RzS3BQgZI dOPkI5FVPgtUxNlWqGTzueLzSUV8Tc85Lqskk4EL8Zx16Sjb4YEbhvvshfVJu+MB5DPnCUaS 2Nl8Db83sQHlm2m2AWU0l0kz+C4iKFY5sib9aacEw/k++j/VDASVIas40c/aaVKC4XyfBP+z U0q1zE7ghizYzATCNZXWMsQl2kL4cm+usHNoTFmKT4eKEREv8wMeVFCaqzAxOjskqzDR3VqF iWnM5b84Yf64vimZYl9G9gVlX1LJvKem3bYMsM6IYF227R00tYQZuLZY+uWHvVH7XTCStAt6 kG1hFtgEWElQlKagtj5yjXwUKZfRd7bdO9XeJlNM28GSFtvp0qSbYs14u3dR/6WUAdaVFWu3 9Uf/oN2Ga5a5LpSmNWVwGi4+saYAWXLtZZQjqNBkSbHatBh8ETUFVZralOqUJBavMMXXrX3B pSQzuXKTEiqqHWVjbCy5LUaPtoFitC2UISpIHHmOCUeSjPyASvjSceUTmB+XVPzmA5xY+Ny0 xXe4bMPx0phffBh1J4+Bxt4jjfm1OAfpqDRRccp2odKkogwoA8pAWzHgXFskG4YLZEjIePu2 DUHvPQSK0pYwO/Dnh+3NoTDx5/ZSKFLfwPIVlKivKivkG3zJwnWKKokz0Fhn3Jhf4ilqyLRn IN2UprQnTDOoDCgDysC6YuCadtKnIIyvhh1vzeQg5GNjYDMCulA7L19WO4Ijap0L5Wg8FKhx MMfV1Mi426q8r4694PpPGVAGEmdAlabEudKQyoAyoAwkjYGz8cVajyLpm58v/TBF1g8TaxtA 0ekHRac/lJ9BsA+sV4way4WR+Rjm+BGa0o+YbJuCRTc/1jgy8Y7yFq2JbOwO6qcM5DwDqjTl fBNQApQBZSCZDJRweqxQetcVSC9MifXG4q5eUIh6QRnqDSWoF5ShPvDvB4WnF6bO/PV6/CYV 4o0Uef98O6bSFsP5M+L8jMs/I97P+PRwerhcfizxd/9nNBVlQBlIEgPNUppKOspbeKgP8vJi +HEFHnsIHmLPXIvbxYPOcG40PD7KiLpjaf3mGhLnVwox+J++Mhy/2mKanum5o9eQbl3wOu3I rOfHa14eEA/2WuSA7hj89Opwx1rc2/rH7PAHB/Sv9dJy4HZ9N8Lz0+laL0+MDzsy6oX1rtV5 afK6dw1XfBNuzy8Ed8S3023gNquQBtLBzly1+MyuFvuhMA5uraIMKAOpYqCEu/N3lE61Eemc F8a2FyFsf+FIF7xbuL1JVzyQ3WB2g5um56ad/nhfcL85f3MxeNZL1O4Z+AcFiO+pX2Gdi+ef U2q/4h5z8S76BfaZWHf0s647qmdPLcrAOmGgWUpTgxw6gncBHumANHDAP2F3fEKNxK2/TVyi DZxRR9DP2plZinXX24MeXojov6a+zwr410cN+NWnG/WL/mD0E23ggFdj7Nd/9BvNR6eoCYOb Nd0E4MVKpbEGhfGVLuObeEH/xg/l5k6oVA6p5Pl2xovGYTr1SpzvF0vDVxzr40A5jF1jGrje 4J7wYxhoiVQyfUQVQ94jzLzUBq7ZMPS1diqOUBSxX0LdTGQcG22FZ6PaGtuXAZdVlAHLgFOC vYaqsKdXqJ0UFbjY2ytPiupohqUoDNMN4ZqR9ngm2qM9toeS0h7ttwOehfZof1ws7fkhwQ64 3hH+nfB8dEaYzojjKT759ds72tv6JsI1EOumifiVMMpwP+4nV4a0aS7A81OGB3kBrpe5tfLr 9NVSil15+SNLRRlQBtKUAftsNzd7XrySqA4yOWpuETWxw6F3vW/UxCZDDvSDEHYlpH8IbxDq MCHsWOi5qzuKg3cRx6FCEeOb0B08N8PTv94s8O0YJgrTH3qIZ+JNE8ZL0gtLP17nPfCSxPtS wggYxtBWGAl54XGNZp6BP15mYby4GD4MhcQzkVJevR3qjbVj9CeP8ZAfqkC0hxnWM301yL/m +OG8+1j/qJ8Xj350+2n4ZmN+jYdBsjkmGI1EiTnqhqqQugg6x67duksoD5UeRhXQBBxUdNDP 4bWwf43hPDfDIpx/zQ9Pu+cO+Nvrjfk7oZB3Xy+eE7XDz3Pba3TjmvVjnEaBhsAnwrsWNa3b mt4GkYEwXu3zKYIgpmcyrOeOmvHu+s1AwWDQzjgevY3508/F1+hEXV3MTrdpxC8a1vXCYsC2 tlauuPxyGRSWZ4scqS4ISQ2e7bp8jBKj0Rs8kMwtn1v/GeBeQcbbL6gAxWpo52gPr/n7CVl7 EfyKkIin1HgEJOOfwY8LbszpyErkdwVoWeGZ/t5F3JNtCd4j3E9tKcItwftnCV48S7Bb2tIS X2lKRq40TWVAGUgxA/5bNsU31du1joFjobD1hoIFRRMzBZIX6ih5GOHJw6/rfK/zYQdUIHn4 le27qYxBpYRmiL4Kdl6HG0qkd51pRJXE2HX4ob+PxUccKIwxN+M4gfQCbnQev1EC0cn4aTeu BPrhbTwbhmlG/dApxo3ntY5DjZ19DKCNVaFNVqH9raYJt2fGuSvQpohVCMMBzFVoWxUI6/lh 5KcCP7Qq8OyUQ49eEXFlxeoKWXm3v1ls9pGmJVIGlIFmMaBKU7Po0sApZIBKEpUpTojwU+oO +NcVHl2h5PXA9N2TSxYv8kYyOKrBEQ3C4DAszx714+iIW+df80Y/bFiE86/54b1RFF4L+Nvr nhnnz5GX+vR4LTrC4qVjr9FvDaMx9XHQg3P8zHPDRCa8kSC6G/gHwzAcxBsh8ixRd9Sf8Xxv 36Q9epyJN6pV7+Y4D6/hj2M+9WH8AJ67fnSMo3HB0bI1jKJ5o3rRUb+//eMf2EBIXspzZFUe FJJ8KCZAJdyr81ypCjkSAbxpYGShBpRVIzsRTF9FPJN2rvYLRd01UTvcVRVSjSGm1SX+cSyx wjL/KsqAMqAMtDEDqjS1MaGaXJsx8BulCSlzhReXdnGx7aj6KSY4VNKXgagihgFSb/pqOUx7 9hzX+tiz56AhqigDyoAykN4M6JRHeteP5m4dMLBo0SKZMmWKrF7N4/tUlAFlQBlQBpQBnwFV mrQlKANRBsaMGSNbbLGF7LDDDnL00UdL165d5cYbb2wVP9OnT5fXX3+90TS++uor2WyzzRq9 Zj033XRTue+++6zTM6uqqqRjx45NpstAl156qVx//fUN4qlDGVAGlAFlQBlQBrKTASr03ICh I9ALGARsC+wFHANgdq7tpLS01HTo0ME89dRT9YnOnj3b9OzZ0zz88MP1fs21PPPMM+aAAw5o NBqUHzN37txGr1nPG264wey1117W6ZlQwsx6661nqqurG/gHHUuWLDFLly4Neq0zO+sqWmes O9Yh65J1yrplHeuPN5CgogwoA+nPgL6s0r+ONIcpYODf//637LHHHnLSSSfV361///7y/PPP S/fu3T2/iooKOeuss6Rfv34CRUa+/fZbz3/ixIly+umny1133SUbbbSRbL/99jJhwgSZOnWq XHvttfLll1/KhRde6LmZ/r333ivDhw+Xn376Sa644govjTosQr/yyisFSprstNNOMmLECM// hBNOkE8//VQ4ZWjl5ZdflqOOOkoKCgrkvffek6FDh0rnzp290bEFC7gFkAiUP3nppZc8+7x5 82T//ff3Rs4Yj3mjNFUe76L+UwaUAWVAGVAGlIGMYSClI00HH3ywuemmm9Y4GgOFxxxxxBEG 653Ms88+6432cEQHSpHJy8szF110kZk2bZo58sgjzSGHHOKNBN19990GypjhSBam/7zRLI4c vf322168wYMHe/eE0ma22morg+k8884775ji4mIDpcq7ts0225hHHnnEs9fU1Jhu3bqZDz74 wPzyyy+mS5cuBoqTgVJl/u///s8ceOCBXrhLLrnEXHfddZ59t9128/LG8FDSDJQ6z7+p8ngX 2/AfWpyONGXMY6cZVQaUAWVAGchEBlKqNA0bNsxQcWlKONUVDofNrFmz6oNQ+XnyySc95YeK TG1trXftiy++MJtssolnD07PUWmicrV48WLvGpUtqzRtvfXWDaYGn3jiCTN58mQvHEaw6pWh Dz/80PTp0wc7G9SZ2267rd6fAcvKyqicmBUrVhirNFGJC2GLVyxq99KqrKw0N998s6Gy11R5 vIBt+I95AjilqtNzIEFFGVAGMpcBnZ7L3LrTnLchA5xW48LseIHSIW+88YbMnDkT2ye53tQZ p9CIb775Rux0WK9evQRKiBcda6Oa/PJuwIABAgUr/jaC9VOy+eab1/ufcsopMmTIEM/9hz/8 QT766COBMiScmjvuuOOwo3lIoMB5+bGRmIf27ds3mMpjugMHDpSiIn/DbIxgeQvEGXdN5bFp qqkMKAPKgDIQY4CbB6ooAznPANcF/e1vf/M2lQxu8Hj77bd7X9RRocEokaeoUDGhLFu2TAoL C701QlRiWiP8im7+/Pn1Sbz//vvel3VcP7XhhhvKjjvu6H0t9+qrr9avVeKXfpMmTaqPw7VL zBsVQCtMd+HChcI1U1TqML3nrdP63e9+12R5bFw1lQFlQBlQBhoy0Lo3fcO01KUMZCwD5557 ruTn50tJSYlgms0rB7cKeOWVV7xF3hytWX/99QXTbd41fPXmKVMciVqTUNFKZL+nQw891Esb X8R5ytOpp54qWK9UnzQXhGPNlaek7bzzzp4/1k0Jlas5c+Z4buZ33333bbCrNxUu5v3FF1/0 wmDazxs5a2l56jOkFmVAGVAGlAFlQBlIGwao0KdsywEu4bFrkdq1a+dtNcDtBl577bX61T2Y IvMWYWPUyVvQfeutt3rXuDYJI1X14fB1mtlggw08N9dAMR18XectBN94443rwwXXNGGUyFsI 3rdvXwNFx9xzzz314WjBaJG3Hgpf4zXwP+OMMwy+ojMYOTKY+jPjx4/3rts1TXRwiwJupzBo 0CDvHuPGjfPCNFUe72Ib/kM96pqmtHmsNCPKgDLQGgac1kTWuMpAEhmg0tTg7Dm4k36MCnQF b30R1/twmis4VceyciSIo0tQbuq3IqD/moRTYpFIxJs6W1M4XuMIFtO266PWFp7XOa23fPly 4UaYTcXj/bEA3Us7mGZLyhOMn4hdj1FJhCUNowwoA5nAgCpNmVBLuZnHdaI05SbVyS21Kk3J 5VdTVwaUgdQxoGuaUse13kkZUAaUAWVAGVAGMpgBVZoyuPI068qAMqAMKAPKgDKQOgZUaUod 13qnHGIAG002KC2/yON6paZkbdcbi8f1SNy7SUUZUAaUAWUgNQyo0pQanvUuOcQAN8nknk8U nhnHjSrx1ZzsueeenolDeOvZWNv1k08+2Ttjjhtmcg8mbnuAL+M8ZYl7L+FYF2+ReX2CalEG lAFlQBlIGgOqNCWNWk04FxngV3eXX365d/guy3/11Vd7m0jOmDHD21Wc+yX997//9Xb2TuQ6 wzC9VatWeQfs4mgVwbl18vjjjwu2RvAO4uVBwSrKgDKgDCgDyWdAlabkc6x3yCEGqNB0797d O2aFxeZxJb179/YUJ7px+K6MHDlSeJwKZW3XvUCBf9zwkhtdfvzxx57vmWeeKTgzz9vxOxBM rcqAMqAMKANJYECPUUkCqZpk7jKAjS29/ZIsA0cffbRceuml3t5PBx54oOy9996yzz772Muy tuv1AaMWpv/88897U3T06tGjh6cw4TDgBufQxcdTtzKgDCgDykDrGdCRptZzqCkoA/UM/Pjj j96xJdbjvPPOk/fee887/uSqq67yzpE7/PDDZenSpV6QtV1noDvuuMPbZJP7HW233XZeGhxt ssL1UsEz6Ky/msqAMqAMKANty4AqTW3Lp6aW4wxwt3AcodKABS4A5xokHqj74YcfChWrG2+8 sT7M2q5z4Td38yYqKio8Jaxz58718fv37y8rV66sd6tFGVAGlAFlIDkMqNKUHF411RxlgAf0 2u0GeHRJUVGR/Pzzz/VsDB8+XM466yyZPn2699Xbmq7bSMXFxdKtWzcPDB8v/AKPB/CqKAPK gDKgDCSXAVWaksuvpp5jDGy99dbCL+UoOEjXW2fEr9v4VR2lsrJSPvjgA2G4tV33IiTwb/bs 2bLFFlskEFKDKAPKgDKgDLSGAVWaWsOexlUG4hgYNmxYvdLES4888oh8++233td0O+ywg2y+ +ebCL+DsXk1rux6X/G+c3OByyZIlOtL0G2bUQxlQBpSBtmdAD+xte041xbZhgAo9v+4sBNoB HYBOQBegGzDKGAMjvYRrjrbccksZP368dOrE7Iown9xaoLy8XIYOHSrhcLhBptd2vUHgOMeo UaPkf//7nzz66KNxV9LHqQf2pk9daE6UAWWgdQyo0tQ6/jR28hjISKWJdDz00EPewuwrrrgi eexEU953333liSee8HYKT/rNWngDVZpaSJxGUwaUgbRjQKfn0q5KNEOZzsD//d//yUYbbZT0 YixfvlyomPFoFRVlQBlQBpSB5DOgI03J51jv0DIGmj3SxMXWtW6d1JmoWe+GX73dDdh9/2B4 2uuiaTBOk25cczHtVmf8NHw7/fz0Gc/aaQave3bcg5OL9lpjJqftGNb7a2D349Hfux4NY+2k m9es4LIn1s9Oa8bcgn2g/DCO4C/q8O0xf9p4jX++HW78hZwQEDSD9pD86+67RTbs8prkOZWS F14t+aHVMKsl7FRJKFSNyBEkU4M0a2HWeSbthAuCaYajbs8/FAEDETFRs86pEVMHdxiojSBd uKsjUpcfkdULInLvDIQPEAKHijKgDCgDLWFAlaaWsJaOcYYPz5MBWAPUDigAwkAIcID8SNgz 6wryJa8GC2ocrBXK53ohH8bk19utH03GDbobsxvcKSQN49PPCfjR3VjcoB/v1VQ4gxJJNI8G 6RqErXU7tu/YwVNaqCjVQolRUQaaZsBU4VrjMLI6ds1ZjbZbgYVoFWhzlSIh304/F34OEApX oOHBX1aJ466Q2oqVcteYcqShjbDpCtArykBWMNAapSkY17cfi9cNZdFw39y03DeXVTnSvkdI 1qvGqyeC7rFjSDrUOLK61pFwcUiKYDqRkETaOVJQ59trimHWoDt2kUY+Rh1qQ+jrfVNo1gHh kLghdMhRe9iB3YV/CP51sMMMwc8E7Lzuwo/+DONdj8az/l6nz3iu39k7tFMRiPrRtJ087ez8 GbbeHlUS4t34KeyF9ZUFa7dmTEGx8YJKhXePJpQPsEjac1042pGH5hDGyIdnovp9N/zq7aGA 3fdn+IbX/TTo519rxO01LRCP6mc43ruhnX5+usGRGKbnhUU++XAErzUcrUFz90ZvOJaDvybs jGNHf6yd7YBxrCCIJ9aP4SkxN9QDjEbFRp78oSm6GxulioXz48RGyTjy5Y+qBc1LL7tMZKP1 npTCvNVSgJGlgrwaPNI1UhB2QRqICzFDUQW+kTZunwdjos+Ig48DPCUayjQVaqcAhYHibny7 9yMAftbteB8TsMjJEw7fecqWswL35U6jFnDLcvhhC/jQEs80Lu1L8f5ZKk7tEqmUpXL3V1Tc VJQBZSDNGYi9WRPJ6PV7vYUXw0GJBNUwqWbA+NMZ3vRFYCrDOA2nOxpcbyKOH8afLmkQPpAu /e1UihudWgn60W7gb8PYdExcGkH/UHQqBnMs3hBSBWZVllWFZdnqPJiFsryqnZRH2kt1TWe4 Hy9fUe4pRVZBsspAqpnX+62ZgWi9HItQUBqoQHgKxSqYGMmRaoBtN5mjNI6cNrwQ310WQbUq glpWJHluMdomdgp1inyTdsCYYjFOe2ii7dF+20OrhenG3AI/4XWDLzodfB5pAJjGdPS0VyTS QqlEGguQlwW47wKk6dtd+AncDkxjfpVpS+bJqMmcblRRBpSBdcAAf7m1TOzCCMZ2nNhPU88d /X1qf5LyumfHz1AvLEy6m7JjzBsvCaQJ08ajHW8vzy9oep1y9JqnIDAMXsAOlQXvPlQa6EcT iPpbuxef4eBPu0HH7ZkBN1/q9ddCfhh2/kE/hmFcG9a6Gc4qA07Yv27XaTAMrzVQJKIKg+cH O00irw7hXN4D6zzqoFTU1Ep1Za2UzaiVUV7ZcOusEowYeqMP8VsOUJnzRtY6FBZnVYG1MElj wMiI0XZqLlk3ceSK3bAtRn5nCdd1whReJ7yyYDqd8fbpgvdRN6Ar3kld8TzDBBxunRH1E6cd rg+E/0D4x8QbhKMTnvTfrIeRG/ZahDTmIq1f4fcr0p+Le83FIPpMvBt+ljs+WxRLQG3KgDLQ lgwEH8+2TFfTUgZay0BTSlNa79PU2kJnY/w0GGlKf1rPG95BukZ6icnrhSlLmIT0gtLlm470 RiE2gKLUF9rTmn/sGoP1Vc5MhAXkZw+OmSa1VVPk9m84cqWiDCgDLWRAlaYWEqfRks6AKk1J pzg1N1ClqU15DmFEqzfWhG2AkSkgTEWqH+z9oWRtBPtGsK/X5B2NWYZrU4AfMWo9Bcs+p0ht 5XhVpppkTC8oAw0YUKWpAR3qSCMGVGlKo8poTVZUaWoNey2Ie9Ww9SQ/HwpU3SAsOIcSJRtj 5GlzKEmbN6lQGTMfdxoLjMMygHH47mas3Dl6dgvurlGUgaxmQJWmrK7ejC6cKk0ZXX2xzKvS FONindv+Mry3FEN5cp0h2CoEipQMhUK1DRSrzo3kbSEUra+AL8QJfSlzzZjo2rBGgqqXMpAb DKjSlBv1nImlVKUpE2utkTyr0tQIKenl5ch1u2JkqmBbfICzLZQomM72yGLPuGziqz2D0Sjn Yyw4/0BWlH6BjUP59aOKMpAzDKjSlDNVnXEFVaUp46qs8Qyr0tQ4L2nve9WwjbAH7q5QoHZF XncDMCqF8SkrxmBvKeczTOd9gI+S35NbPp9gL6mpDGQrA6o0ZWvNZn65VGnK/Dr0SqBKU5ZU 5IU7d5L12u2C6bp9MZ23L6b2toZCFetDjMzBSNWrGI16TT6FMjV6NPffUlEGsoqBWIPPqmJp YbKAAVWasqASWQRVmrKkIuOLcfXuPbAf1d7YNW0/KFAHoaL7BIIshd+b2D/qOShQ76sCFWBG rRnNgCpNGV19WZ15VZqypHpVacqSilxzMRy5fq+dMMp0BIIdDgVq81hwsxiq8yhM4z0pt3zy VcxfbcpA5jGgSlPm1Vmu5FiVpiypaVWasqQim1OMq4dtKuE8nEbqnICpvC1iUc1UHFD4mLhV I3VvqBgrasscBlRp8utqIow7gWeA0cBAgL+UeDYWhUd58BiGHsClwDBgTyAojMvjWk4GbHrY eE5uBSj2UF0epUK5DRgHvEZHnPBeuX5GiCpNcY0iU52qNGVqzbVRvq/ZfSscynwSRpv+GJjC 4/l5T0ut+afcPnpSG91Jk1EGks4AOyaV3zKAQzjl2t96ez7P4j+VpuDnuDhRXQ4GqDgF5a9w 8BpxP/B4wH0T7JTJAJXXIHJdYSIvKsqAMpANDNz+2URMy10pU0f3wyjToVhIzh+KPArmdMlz fpDrh78rN+y5XzYUVcuQ/Qyo0tR4HVPZORfYpJHL/FU0BeDcvZV9YOFBsu9bDzWVAWVAGVAG AgzwYPFbR78pt4w+QiI1fLfei8XiFRh92h87GbwH5WmiXDv8VBk+nAqVijKQlgyo0tR4teAE cfk7cG/jl70RpaMD146C/UWAilNzhTvx/iEO3FhORRlQBpSB7GTgzs9nys0fXyQ1Nf0w8nQ1 ClkK5WlLHFY8QnbHj9Lr9zgRfunePwVnB6ydeVasOw5sPQTNNn2G0r1Rtmlhm5nYPxB+Y+DI RuI9B7+9gPUArlU6HOC0XUuEaZwdh91aklCWxTEoT1Pg2jGVzGKAddZUfdI/E+V6ZBr7Enly Pv6zHHv7zvr/nIriqPXWANcz9gaCwvfLCqAIsOltBDvX/BD8IcZ0rfsH2CncibsxPg/xrmbK vzs/X4aRpzulbOUAMXWnItvToTxtgoOIn5Ybhk+QG/bisod0EXbEViHie9+CI2OK9OPA1g9N W2+sw1YJK1qlcQb4UroY4Fqk0UBQZsExBjgUmAMw7KdAS2Q2Iu3dkog5FCfYObDzVaUp8yrf 1luwLjOvFGvO8XJcvhdBfrDqAAAgAElEQVTYBogfdZ4Av2kAlaQHASt0vwLw4w8rM2HhOkjK 7sCbQGc64oRfpXGpQObLw2PI10g5FovDB+95ioScG7DMcyj83sRWBh9B37xcbvl03DoqKDta 29my86XdmtbOrAXD0a2Segbs+4V35jvHuq2dJuvJ+sPaPFGlac18vYXL/JV4TSPBOLJ0NDAL eB5gJai0PQO2cdNkgyf4i10lsxhgndn6C9ZpZpVizbnlD6f2AH9scXo/Xuw7wypN+QjAH17/ 396ZwEtVnOm7LpugIgqicUMSNLglGk2M4gZ/ZTSaGHcj6ji4Je6IywRFjQoaM65oJEQNiBkd t3HcJS6AOKgRN9SoSVTclWBUVBBEet6nb3/8j23fSzfc29x7+/1+v6erTp0651S9dU7Vd+qc 7t6/OGOZy22vz+G9pzR5bNp3YzlPPY/KO091uqnMtXtSs07j0oI5w6r8UwXhCIVzhLMEMXtB GOsiL81H3FY9BeJaiL6FvoZ49DsR0i6sC4vtYnmxoZ2mxUqUhihLqTucm5R+nmBqfXexpMZF 173Exh8qreIGLbGftpIUzhIn/wK00VfZ3TG1jtblPKbNaLvovFpHySsv5fHa5BFxvXinaHMe 658peogPxADBY7cHxZLYrtpo08yGzFbF48JMciuM3vwCulyWhvS/Nq2UhssHOVbL+rbd8nun 4f3PSTM/GZXqZ6eau3L0MRCOEv01MKvo/kcitAKj/1lZRP9DkcNxqniMtdOEfI3b37V6lCie bXpPaY+JdQSP6pbUNtCGdKDF1k0Js4sTa3CZk5oTPJwmpvGBu3M04uchuLtfXnQW3L1zXtPJ 2aqnAO2DY0TbMHjzG2efCc5hbiyi3cJpIn/FHZa2aenG47KxgpmmQUWF/ZuWnxHcZJFnL3Gz QJMlsX21ETqHcaPVNpymqNGlk3BOTk7D+2l2rtMlet/pJ5p9ujCtvtIRcp6O1bfxHoiszRCG UxQOE/0K0MfU5XJt8fRtBhWX8S4LN9fLqRj0QdGmlIrrjuWKGtJOE9Kl9N36IP/ZPxOP6OmK QLHtVJxQWM7uL7IcH5FMeIfi2UbMrHJUCnAyQzhMDMrAO2QMzLz3wV0fRh7uTiPNThOqVM+i jWgDmCtwmghpK9os2i8cp2hfrWpTdrZqw/tL/UvUKh7RXat1PxX7lMhTbtJgZXyx3MytOt+I qa+o/LvrEd3O6hEuU6/ZVw7U/Xrf6Sb9uvjQNPLRt5uhfvTN9CNZp4n+hQHY1roU4Iaa9sSi 34mxhbBss9NUtlTOWGUFik9sBlpgQGYAZjAOhynS6dC4CyQ9LhBFbVVQgPaiHbibo41wlLKO E21GerRjzDRFO2tVmzFm134prhBvFNWK9x9HiJ0FmkwVtnIVOGfihHTkFt/RTNOJ2uRMXeX7 pfbL7apZp1/poehlzfDHwOE40afQt+AwMQDbWpcC0Wb0N/Q9QcW1sNNUsWTeoMoKxEkejhGd F+dtnLuRzgCN00R63B0qaquSAtEJMZuEc5R1nHiEFLNN4TiF01Sl4lX9MON1xJ+LncSdmaMz I/Jnwbfs/ktwfi+p8Z5G96KNmd3DGWu7Vv8u02/S6dvfkNq145Hd3rriL0zb5/4tbdP/qDRy 0iNNVPlihwmniT6mSxPt37upngK0GX0O40X0VRFWVIoYeCrayJmtQJUUyDpMzGDENDkhFo/q 6MjCYcKpstOEOtW16IDolLKOEwN4zDrhMNGOEJ3X0jgN2k2LNep1nMBBKrbrlTBG3FC8osLl qSXyH660a0qkt72kkQ+/qUrto1mmXXTFywnVTxS0yz2s33can+bMPzVdOHVmE1Q66zjRx3im qQlEXQa7YKaJfin6J8aIJXoasUQbLYMKt8RDcgH1EdzZvSUYNLKGQxoDSTa9ueI4C3jTn4ps vLmOV439hvNDfdAz7vTouKIDIy0gX2zjc1tiVNHCweWcp2MK54gQxwmHKULSogOr5jWiw9ra pALHrbdc6rb2L3X167FonQbI3EeawztD/3c3Wq/acz5WavQf9Cf0LfQ39K182aRrgYf9IriU aAVW+JL19irqJwWY+ebJBP1R3MCVffO2LAaWrVXQsWIDsaR2iTbkmyLnLOkOlmI7XvLmuAj/ qlhbUCem2s8TNAT2R/GQ+AMLzWBogIN0hthdjBKUa1Ym3lzH1iGqYpyf0XmF4xTOUzhQkU4I OE2xnaK2KilApxOOE4MUhGOUnWEiLdLJE9sparMCS6nA8H59Ut1yo9QD7JrfUy73nL7ndkI6 Z/LECvdMHxJ9DbMUOEx8Sxenicei99tpkgqtwApO00AVlW9i4jgx0RGvDMQNHP1QWcaJUW3D a+8p3lqKA7P9QlHqq/pLsdvFbrqjchwtfiEQflPxtFhF7FDgKIVYcztNvMtAQ+M84hy9IkYW xbXY6i2cIMJwjAhxmrLLrI+8dpokRpWNczHg2oRwngjjji7SWE9+QpsVaFoFzhzwU+3wYvGt /I5zuVtTbuEpacTDr5U80PD+Z2ku9Jr0m0kxLoXTxIx2zDKtqHg3gdN0j50mqdAKrOA04UTj NPHzJ0w2xGwTN3TcxNEXlWXN7TTxDYfDBB76bwW/XbKJOE0MEmcKZkZ+LDYTN4mTBZXYThwu DhHHCowZnRcF307BYxwr1hBXCfJzQQwRkwQzQhz/JfFzgXNxqHhWYEcK8mK/E8zUYNuLYeL7 YqIgH2J3EFPFvwgG6wlinFhL7CE2EuTfRfAOB07T24L99RG3CMozT9wuxgl0oEw4fxcJ8r4g LhAPisbqcLzW0/A5cb7gRGAbOgviaEsZsrabFjgO7XGb+HfBNCV1ooNZRzwgcAzfF0MFdf2B 2EKMEW+KXwnqeJiYJprTwgEixCkKKBdxwlgXeZWUTyO0VUcBzkOMEBYWwi8L8QhJj3WRV0k2 K9DECuQf2a01VL/rpH62bkXtfb7+HPhK9Zoj00WTZi062rDteqaOHd7S8nvpi9zO6fxJjBn0 JR1EJ4HTxPZdBU7TKuIOO01SoRVYwWnaXUXFB/hY4DswRjL2zRcVOU0MOs1lG2jHh4qdxb+K E8S3BSfe5gJj+TyBkzBQ/IvAI8ToZHEwMByTcwQn+o3im4IBHmP5OdFbjBC3im8IHIODxJoC R+Z1wXrsp2KYwInZXxwlDhTY5eJCsaVAn2MERllfFjhQPxN3iCsEF9vjggHgn6K7CDtckUvE IEHdjhPYJmKkuFbMEMeKdwW6jBfst040Vodvav264r/FI2KcoH4Rv0vxrJEXrU4RlAVH6HiB jqSjRR/xDzFWYKxTh5M/xkkKfy3Q42DBcWiT5jZ0Db5UHDjJvxCc8DhvnCdcAFlwKE31NMhq T5w2oW1oI9qKNov2i/YkrCVbR5XdUHSupUovs7pe/vd5acTk89PnX/RVD0K/2kHftBuSVqh7 RS+Pn55O3YaxSKkdBuuzk+il+esp6fTt6PvD6IcDxgPgRs3WuhSIm2zaL9qTsGLrUPEW5W+w prKuJnqKKWJrMVv0EFm7VguTCwkMyrsJHJKpBRTk7Ql94nhlbX0tbCN+LNj3LQLHhH38ReBV DhV01heKcQJj4P+tmMCC7DKxn2CmizL3FQ+LQ8VKAltPzCAi21fgRGBbinsFDcBF+I4Iu10R 9olxvL0E5cAuFlfnYyndrfBZ8Zl4XmwgVhRYQ3WoX1vvPX+ihX+I10XEce6yhgP5gLizkIhO vcXB4lFxv8DOEu+JqPetiv+XwN4Xo8WfBSfhdaIaFoMsGjNLgRGyjEVYHM+v9EdVFcg6QhGP 9qMg2Xi5BXtLGX8knit3g6J89D2/F98pSq/GItcRN0hriTcEDuSOYoY4Rbwiim2MEq4U9Alh 3OgNEpz3Y8WfRCmjz9pTzBE3CPoWjhnGtcJ1yzXNjRX9wi6i2C5QQkN6lyrf4o7L/tuJU8UA 8bqgny++uVNSE9tv/pc++ZB02nYXpfbtfy3H6UeafRqROncams7or58sSP/2/49Yt2pq1+Gh NHz7vfQob2IhHc0C6gC21qVAtFu0I+ESWXM2/kMq0XjxsKBjOFR8Kortb5mE1xTfJrOcjT6Z XSjEv6nwJYHDFPaqIqsVFhjkcZgwjt0lH6t3gE5XfGaB8xWyDZ3LkeJE8U9xmegoMDrutfKx ekdlVcXXFtsK6jdMTBZZm5JZeFrx7pnlbH1wXv9HzBIcM2sN1SGbp5x4b2V6MZNxmuK3CDTE CQrjeDhvPQsJ1DtsviJ/KSyga6dYUaWQAZdBAzh+sEBx0/I0iPYhjHajDSu1ftrg5Uo3yuTn 2vtJZrlaUW58bhfXC26Y6A+5WeovzhDXiJVFGGX8vaAPyqbvoOXfiQmFkO3QpNj2V8JZ4lZx hThb0O9m7Tgt7CN6FBJxjChjwM3pQPGBKLaGylfOcdkXDhM60MdRRvRYT1THzpsyPZ07ade0 MDdAB3xYdJcDda7CPl8pQJ1m+Ova3ZV+uf1+Sq8rQbuv5PdCa1CANivVlpFWdh2as/G7qRRc wAy+x4qDBXdLxdY1k/AdxRm0y7UXlHENka1HXy0/WtgBHXUp+1iJlAlHCdgHs1M4AVPF+gLn DSeLu0TseUH5uHMcIU4UvxSHid+Kb4gLRNZwrMK+rchjsaAwBo/2il8vxgu02llkraE6ZPOU E8dhop5h1HE7gYY4f2E4hp+JVwsJTXX82H9ThmhYDOU1y06D4vaI87ycdt9eme4VzJoyQxuO wyjF1xHcoFwqLhJviodEbxF2jyIbFPhPhceJSYKB+VyB0Vdw/b4j3hbDBR0nxrH3ENPEa4I+ Iuy7ikwWHHecoB/AuMbHiHfFk+KHIuxsRSg7/dFocbig32CWp7u4TfxIhNG/cO19EgmF8GiF F4o/CMpwuxgsim2gEi4R48QUcbVg4A/bSBH64AcjQeGz4uYM7GOQQJ9ia6h8iztu7GdTRdCb dpognhI7iuraiEmT0jkTd1DP0V8Hnlny4HV1HVPHdtelU7c9suR6J9asAllno6lF2Fc7/K1g 9obOiI6IjqLY9lJCB7Gi2Fs8IrBeggu8MXtbK2cItsPoWNcXU1loxOhs9xedC4xVeJKgI3xa dBPTxY0iyjxf8d+IceJVsYugU50k6CjpAGImStG8/UyfHQWdP53X/aLYVlFCD3GXWCgOFk1l lGfPws7YPx3UuqK9uEysLkgfKEjHdhcPiBwLNitQRQUu17FwDrYU9E3HCOz7YnnBtYgj9JHY VvxV4ACFfa4I1xB5OY8597mR6So2E9jRghsTrtn/Jw4UhwgMp2CYwCGhHFwj7It+AUfjdrGd oC8YL7BfiDniu+IP4vcibAdF2IYbqq0Fx2a//QSO1Eyxmgg7T5ETxT8joRD2UfhMJu0Vxenn iu1MJVyVSaSsUwrLnRReI9AUjUoZ9ea6f7DUSqU1VL7Gjpvd1QFa+JP4luBYtAHO07KxufNe 1Ivhq4iG+7rOHS9MJ2976rIpoI/aEhXAWWku4+6FDuhV8a6go+EOi84la59q4a+ii/iLoJPD thIXCTqdxoxO8zpxmlhTnCM4VmM2UivvFK+JduJZ8XMxW9wt3hGPi1XFEBFGnf4h/kdQL8q9 tugt7hNviqy9oQXyUTeOgYNSbLOUME7grNFZThVPCDrXcWJpbAttPEbcJigrx39J0B44haR/ KXCSWP+UoIPfQ9isQDUV6KiD4UD0FQ+LQ8VKotjeUwLXPAPdSSKu4YWK7yWwzUVnwY3bB2Jr EXa4IpeJuFa5sTtAjBPYcPFcgdMUri9+ILiOLxYY6fQRKwhuTLhmMPY1MR+r/6BOlGtvMaE+ Ke8QPqT4ArG9uKSQ3ljQWys/zmSg7CtmliNKmTAcPcqKU4JG2DmCfovrv5S1V+KvxE9LrVxM WmPHLbXpGUocJJ4Rn5fKUJW0zp0G6/EcbVTaCl+7Sst3HJpO6rdGumgqfbKtxhXo0Iz15yLf UHxb4Gi8L7BHxQb5WP3HTQrGi24iLj7WkA7YsPpg0Wfdolj9N7vokPoIOjacMIzjcOcYhpOw TmHhnwq3FWyD/b0+yH8epc8LRBfxYj7lqx+TtLiD6C6+JTgm+yu2gwoJdGA4X29kMsRxI+kX iqwhPhOzBR3YyoIOv6E6nKh1YYdERGE2foeWs3ey1O10gaOU7YQP0/JwwTFxnliPZY/B8rp8 FOzPCnvFgkMrsJQKfKHtjxQM9lx/twgG+mLjWs0VErleFgr6E264sjZDC1w/xdZbCY9nErl+ e2aWs30QfQn9wHqC63CmCGunSA8xQowV3Ig8Iv5DRFkoG/ah+J5gm/3Ey2IHwX653hZnc5SB PiQMZy3bZ0U64cbiLjFNcEz6ph+InwmOvbmgr+Va5vqNfmlPxd8WODJLYqWO29B+mGU6Rtwp fiXo/6ptdXKYjij7oCssd0A6aZue6XeP/0f6bEHZmzlj21OgQzNXab72/3wZx6Dzg3KsvzIN FHSsYWw7PRbKDOl4G+p4ZpSxDzqjUs5S8aZ0eNExFa/LLtPphuG0lOrwY/3ShA2VmeNny7A0 x/C2VqBSBTppg6liffFdcZoYKQaJrHXNLKym+OrivUza4qIvKMPa4i+FjH0VPlqIE4Sjk0nK 32D8SQl7ZBLXVJzrhePvInBq9hfjBQ7Jp+J/xW6Cm5cdxW3iLEHfhfNylCjH6D/YZ1hvRaL8 kUaIE8axThE4nWE9FeG6/10h4VsK2V9OnFtIw2H9z0K80qCh4xbv524l/Fy8JegXbxW7i+rb sC2768cur0m5uk6pLqdzT2FSWNeuYz5kObews24fO+vx3XJSqktqX7dyGrTZQemqaWhsswLL RIG9dNTvV3jkHyn/QJGdbapwF85uBaxAC1MApwPngFkQjJmP+/Kx+kGWmR4G2HmCWQ2MR09Z 5+EALTP7g0PyNxG2tSLPFRaGKbxOdBb0IQ+KcIYYzDcUYS8rslWBjxUyM4PhyP01H6t/7Pbj QnxFhe8L6oKtJh4XP2ChyDbTMnUsZTOUuENmxcmK49i1E+sL6raTwKhb9KFjFT9PMLsdUM9i +28lHJJJXE7xueKbmTSia4lSZZyh9Gz5Gjtutnw3aLtfC45H+R4SzHK3RENrOVL59+FwjPuI 74kBYh+hN6FsrUEB2qrQZrQdbUhb0qbcgNHGtHXZ1qHsnM2TkYu3Uru30g2c3wpYgRavwCyV kJmIdwSOBo7HEFFsM5Rwk2gvcAgOFGHXK8IgPT8SSoTXKe1PglnmTwvhBIWN2WNaebnAWXlF rCAOEtgocbN4VtAJ/15QF2ym+IkYIxaIFwV9Lp32bDFclGMcY0fxplhZjBYPCOwY8bGYJqh7 XzFMhD2lyBax0EC4pdLZx2tF69mOsjND1pg1dtxs+ajHneIQwUA2UdCWNivQahTgTstmBayA FWgpCvRWQboIHIxiY6YJR4pZlt6CQZ7Bd3HWTxkY/JmtwtoLZmxwXHDSyjUcOWZfKFvWMVtF y70Fs17zRCljdmUDwTFniHLKrWxfMWa6PhEffiW1dS3g6OI0virmtuCiM/uAgxuzYswiriRw WnuImzXLosDW0hUovM+/r8r5gfhIcA1ywzRHcL1yQ7NQlGXLeqaprEI6kxWwAjWjwIwyakoH x6Bbjn1DmY4TMzKZeWfwpcxyuVFmkGIWKbsNTsziHBk6Z2ajlsbeWJqNW8i2n6scL7SQsrgY VqBiBew0VSyZN7ACVmAZKfCyjntthcfWi735x0A3VLids1sBK2AFvqaAnaavSeIEK2AFWqgC OE1QifEeEO8Z2ayAFWhiBT799NPUpYu+WNi+ffryyy/T3Llz04or8iSz7VpFb423XRlcMytg BayAFbACrVOBN998Uz87VZe6d++eevTokVZYYYW04YYbpjvv5L37prO11147Pffcc/kdHn/8 8WmjjTZK7777brrjjjtSnz590k03+b3+plPbe7ICVsAKWAEr0DoUYEKBr6N3FasLXl7/nhgg 9hEt6tv2b7zxBm+l5+bNm5cvl2Z9cueee25OTlTuiy++aLKyvv7664uOoRml3Msvv5zf9+DB g3MjRoxosuM05Y7QpdBmtB1tSFvSprQtbVzR5FFFmbVzmxWwAlbAClgBK9CCFWjXrl3aZptt FpXwpZdeSgceeGC6/PLLU//+/fPp9957bz7eq1evdNBBB6VZs+q/43DxxRenK6+8Mu27775p rbXWSvvvv3/6/HPe30+J2SVmtcg/Z86cfHjRRRelu+66K11zzTXpj3/8Yz6fP6yAFbACVsAK WIHaUaBVzjRdddVVubFjx+bkyOQ23njj3MiRI/OTNk8++WSOmaEBAwbk7rnnntzChQvz6/X4 Lvf+++/n5FDlhg8fns87ZMiQXLdu3XK33HJLbvLkybnevXvnxo8fn18nJyo3ffr0HDNbnTt3 zj3xxBO5mTNn5vbcc8/c2Wefnfvwww+bcpKoSfalU7ZJZ5r8InjtdAKuqRWwAlbACrRhBe6/ //7ELBMvZM+ePTs988wzSQ5SvsbMFt188835d56YJRo9enTabrvt0vz589N6662XHnuM33Ct t/322y/tvffe+YU99tgjMVOVtXXWWSf/DpUcqrTqqqumrl27pp49e6aVV+ZnrNq22Wlq2+3r 2lkBK2AFrECNKHDdddelTp14TUe/3CjHaLPNNktTpkzJOzU4OLwkjvGNt2nTpqUjjjgiffzx x2nNNdfMOz35lfpgOYyXytmXrV4Bv9PkM8EKWAErYAWsQBtTYPnll084Ss8++/XfVMWRuuCC C9Ldd9+d//bbCSeckJ85CgmYrbKVVsDKlNbFqVbAClgBK2AFWpUCn332WX5WSO8Z5Z0inKNd d931a3Xgcdumm26a/5mABQsWpBtvvJGvA34tnxO+roCdpq9r4hQrYAWsgBWwAq1OAX6nicdp /J4S32QbN25c/n2l4orwzbgZM2akLbbYIm2yySb5d5uefvrpdPvttxdn9XKRAnVFy160AlbA ClgBK1DrCjChwDu/bfoPe1955ZW07rrrpg4dOuRfHOd9KH0rrk21vf+wt001pytjBayAFbAC VmDZKMCveIettNJKEXXYiAJ+PNeIOF5lBayAFbACVsAKWIFQwE5TKOHQClgBK2AFrIAVsAKN KGCnqRFxvMoKWAErYAWsgBWwAqGAnaZQwqEVsAJWwApYgTakAP8Rx8vd+guV/Lfq+C85/U1K /gctqeZWW22VX8ePXvJOEz9qefLJJyf94W/+V8X79u2b+A2nrO28887pgAMOyCY5bgWsgBWw AlbACtSwAkwo8NPaXcXqgjemvycGiH1Ek/wvWnPvhP+UGzZs2KLD8N9w66+/fu6SSy7Jp/3w hz/M6VfEF63X367k5GTl7rvvvnya/lol17Fjx9zEiRPzy2PGjMmtscYauQ8++GDRNi09QlsV 2oy2ow1pS9qUtqWNK5o8qiizdm6zAlbAClgBK2AFWqEC/Dccs0RygkqWfsMNN8z/l1zha/pJ TlU65ZRT0uDBg9Pzzz+fn4W6+uqrE78HVavm/56r1ZZ3va2AFbACVqCmFOAvVfj1bx7RhfGr 4fwq+Lx589IDDzyQ/2HMAQOYlKm3s846K/93KzhQgwYNKvkL45G3FkLPNNVCK7uOVsAKWAEr UJMKnH/++fn/lWP2aPPNN0+9evX6yjtJ06dPTxMmTEgPPfRQeu2119JHH32U+NHLMN6J2mmn nfJ/z7LbbrtFskMrYAWsgBWwAlbACuQVaDPvNGlWKTdr1qw8c+fO/corSMXvNLGS/Mccc8yi fHKqcl26dMkdccQROf0BcE7/b7doXWuIqDX9TpMvaitgBayAFbACVmDxCsjhSXw7Dsr5i5SN Ntoo8RgP41t0hx12WDr66KPT6NGjU7du3dKZZ565+IO24Rx+PNeGG9dVswJWwApYASvQmAK8 yzRnzpykGaR02223JX2zbtF7S5deemmaOXNmOvvss1P79u3TlVdemUaNGpWeeuqpxnbZptfZ aWrTzevKWQErYAWsgBVoWIHDDz88/xtO/JYTv8k0cODANHTo0Px7TcwqXXHFFfn17KFfv37p 4IMPTnpUl5+FanivbXdNXdutmmtmBayAFbACVmCJFGBCgW+XLyeWFysK/tF2ZdFD3Kz3eRTY WroChZ9P2Ffl/EB8JGaLT8UcMU8sEAtFWeaZprJkciYrYAWsgBWwAlag1hWw01TrZ4DrbwWs gBWwAlbACpSlgJ2msmRyJitgBayAFbACVqDWFbDTVOtngOtvBayAFbACVsAKlKWAnaayZHIm K2AFrIAVsAJWoNYVsNNU62eA628FrIAVsAJWwAqUpYCdprJkciYrYAWsgBWwAlag1hWw01Tr Z4DrbwWsgBWwAlbACpSlgJ2msmRyJitgBayAFbACVqDWFbDTVOtngOtvBayAFbACVsAKlKWA naayZHImK2AFrIAVsAJWoNYVsNNU62eA628FrIAVsAJWwAqUpYCdprJkciYrYAWsgBWwAlag 1hWw01TrZ4DrbwWsgBWwAlbACpSlgJ2msmRyJitgBayAFbACVqDWFbDTVOtngOtvBayAFbAC VsAKlKWAnaayZHImK2AFrIAVsAJWoNYVsNNU62eA628FrIAVsAJWwAqUpYCdprJkciYrYAWs gBWwAlag1hWw01TrZ4DrbwWsgBWwAlbACpSlgJ2msmRyJitgBayAFbACVqDWFbDTVOtngOtv BayAFbACxQrklNAQC4sze7nFK0CbNdSepJdtdprKlsoZrYAVsAJWoAYVyA62DL52mlrfSRDt lm3LJaqFnaYlks0bWQErYAWsQA0okB1kY+D9sgbq3daqSJtF+2XbtOJ6dqh4C29gBayAFbAC VqC2FGDAZeCFBSJXJ1Noa/kK4CTRZtF+tOUSm52mJZbOG1oBK2AFrEAbV4ABN2YoGHS/KLC/ wm5iJbGCWF50FulDm8EAAAMySURBVB0F46qf4kiEKhpthGNE+3wu5ojPxGzxsYh2ow2jPWnb is1OU8WSeQMrYAWsgBWoAQXiMQ6DbMwwMTDPEwzMnUR7gZFnvog0O02oUj2LNqINYK7AaSKk rWgz2i5mnMgf7ato+WanqXytnNMKWAErYAVqQ4EYUAljQMZxYkBmAGYwDocp0nGYmGki3Y/u JEIVjXaiHZhRoo1wlLKOE21GOnkg6zSxbdlmp6lsqZzRClgBK2AFakyBrNPEoItDxLgZY2c4 TAzQOE2kM8vkmSaJUEXDCQJmkminrOPEo7qYbQrHKZwmrarMouEr28q5rYAVsAJWwAq0bQWy DhMzGDhCOE3hEMWjOpylcJhifeTRKlsVFAinCSc26zjFo1ScWhym4nebKpploh52mlDBZgWs gBWwAlbg6woUO07x2C1mNRiUeSQXj+VwliDyKWqrggLRTrQLjlM4R4TxaI6Q5ezjOS1WZnaa KtPLua2AFbACVqA2FIiBGAeIgTYcIdJZhnhcRxizTOSLvIraqqAAbRLtFW0TL31nZ5giLWam 2KYis9NUkVzObAWsgBWwAjWiAAMqzg8DbFgMzDHTlHWWYobJTlOoVb2QdgnCIQrniTBmmCIt 2pRtKjI7TRXJ5cxWwApYAStQQwrEoJodZGNQxknCacJJyjpMyOOZJlSonkU7ZR0n4jhJtFeE 0XaRr+ISumErlswbWAErYAWsQA0pkJ05CucownCYkCObr4bkaVFVzTpDOEixHHFCLNLrlyr4 tNNUgVjOagWsgBWwAjWrQNYpKo6HKB5TQ4llE+IMhUU86yBl45GvotANXJFczmwFrIAVsAJW IK9AqfGzVJrlqp4C4Shlj1gqLbvecStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAV sAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbAC VsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbA ClgBK2AFrIAVsAJWwApYAStgBaxAa1Lg/wC7AihwYrzWIgAAAABJRU5ErkJggg== --------------050403010308000002090704-- --------------050403060802000800080604-- From bernard_aboba@hotmail.com Fri Jan 22 11:32:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB793A6812 for ; Fri, 22 Jan 2010 11:32:20 -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=-1.184, 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 uYpd7fTGuLJR for ; Fri, 22 Jan 2010 11:32:19 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 0B3953A684D for ; Fri, 22 Jan 2010 11:32:18 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:32:15 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 22 Jan 2010 11:32:14 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CA9B56.8B976CD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqbmZlxNcaTp/3HQAi+rahQ13YelQ== Content-Language: en-us X-OriginalArrivalTime: 22 Jan 2010 19:32:15.0209 (UTC) FILETIME=[9A27ED90:01CA9B99] Subject: [martini] MARTINI Virtual Interim I Minutes X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:32:20 -0000 ------=_NextPart_000_0053_01CA9B56.8B976CD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Spencer has now gone over the minutes from our note-takers, compared them with his own notes, and taken into account corrections that have been submitted. Thanks to our note takers, David Hancock and John Elwell as well as Spencer. The revised minutes are now available here: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/MARTINI-Virtual-Interim- I.htm ------=_NextPart_000_0053_01CA9B56.8B976CD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Spencer has now gone over the minutes from our = note-takers, compared them with his own notes, and taken into account corrections = that have been submitted.

 

Thanks to our note takers, David Hancock and John = Elwell as well as Spencer.

 

The revised minutes are now available = here:

http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/MAR= TINI-Virtual-Interim-I.htm

 

 

 

 

------=_NextPart_000_0053_01CA9B56.8B976CD0-- From BLINDSAY@nortel.com Fri Jan 22 11:33:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E39F3A6855 for ; Fri, 22 Jan 2010 11:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[AWL=-2.398, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 mgBH9upMK7cS for ; Fri, 22 Jan 2010 11:33:00 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B2D4C3A684D for ; Fri, 22 Jan 2010 11:32:59 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0MJWHv04375; Fri, 22 Jan 2010 19:32:17 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CA9B99.79DB2F7B"; type="multipart/alternative" Date: Fri, 22 Jan 2010 14:31:18 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C370FBE@zcarhxm1.corp.nortel.com> In-Reply-To: <4B59DD3F.5030509@nostrum.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqbhqxTF5iqEc4STdy4iYbf7VjMuQACeoHA References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" , "Dean Willis" Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:33:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9B99.79DB2F7B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA9B99.79DB2F7B" ------_=_NextPart_002_01CA9B99.79DB2F7B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, =20 Regarding the case below, you could use a "domain routing" approach for this as well. =20 For example, the SSP could perform an intermediate step (e.g. using a local "Look-Up Function" to borrow from SPEERMINT terminology) that effectively provides the mapping from the E.164 number to the pbx domain and does the conversion from sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com . After that the routing mechanism kicks in. =20 ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, January 22, 2010 12:16 PM To: Dean Willis Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Requirements - rev1 [... text deleted ....]=20 I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this: =20 But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com" (and a similar one for +15005550200). ------_=_NextPart_002_01CA9B99.79DB2F7B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Adam,
 
   Regarding the case below, you = could use a=20 "domain routing" approach for this as well.
 
   For example, the SSP could perform an=20 intermediate step (e.g. using a local "Look-Up Function" to = borrow=20 from SPEERMINT terminology) that effectively provides the mapping from = the E.164=20 number to the pbx domain and does the conversion from sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com. After that the routing mechanism kicks=20 in.
 

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of Adam = Roach
Sent:=20 Friday, January 22, 2010 12:16 PM
To: Dean = Willis
Cc:=20 Hadriel Kaplan; martini@ietf.org
Subject: Re: [martini] = Requirements -=20 rev1

[... text deleted ....] 
I suspect most = people can=20 tell that's wrong by simple inspection. What I'm willing to bet people = are=20 expecting is something more like this:

3D""=20

But that's most certainly = not the=20 "domain routing" model Dean is talking about. In fact, it's pretty much = the=20 "contact routing" model straight up, with an AOR to Contact mapping of = "sip:+15005550100@centricvoice.= com=20 =3D> sip:+15005550100@pan-am.com" = (and a=20 similar one for +15005550200).

------_=_NextPart_002_01CA9B99.79DB2F7B-- ------_=_NextPart_001_01CA9B99.79DB2F7B Content-Type: image/png; name="martini-example-4.png" Content-Transfer-Encoding: base64 Content-ID: <406432718@22012010-2A9C> Content-Description: martini-example-4.png Content-Location: martini-example-4.png iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAAeAGt k81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UURBC8ePDm RS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn1tSLly6ro3tQ MIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzTd3x6GoKNRsUk3yUn 3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZeRS02x3mj4mcJwzH5dzY e/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVSZqpebSEp0yljx4EjO0HwLQBG 6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw5B39ncO6SJcGPN4ByveAPMcHHOd+ AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmI a81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXO et9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEIDUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+Rd pzrObbdZb/jqKv9IK6HmbONUQk1q8xp+A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAg AElEQVR4AexdB5wURfr9ejawCywZyVEUwYjxzKCY9UynnoqZv2c8w3lGTtd8euehYjoT5oQ5B5IJ z0BUEMmKBIElbWDDbNf/ve6pnd5xNqeZ3e/b39vK1VWverrfVNV0i6gpA8qAMqAMKAPKgDKgDCgD yoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPK gDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qA MqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMJBkDTpK1V5urDCQM Axk9XReN0c9QwoxIvTTEFK4MheqlJq1EGVAGWhQDqS2qt9pZZaB+GXC2rFA9Vb+UNm1tmb2MDmjT DoEeXRlIWgb0m1jSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIky EtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVA BVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFl IFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaU AWVAGUhaBlRQJe3QacOVgdozsOo3I1u2mNpX0AQli4uTq71NQJEeUhlQBpqQARVUTUi+HloZqC4D 515qJLNXFIN2N3LlGCPhsC8yCiCO2vQxctZF5UXHex8b+cNh0bhHxhvZ53Ajh58ksv2+IsefaeS3 tdH0YHu22SN6PB6723ZGjjjFyK8r4+cPlq1vf856I312EjGm8Y9d333R+pQBZaB5MqCCqnmOq/aq mTEwfbbIS4+LbFnhyKalvv+DSSJ3j/M7OvsHkTatRd78QGT9hqjomDFHZFcIEdrET428/q7IOy+I zP7MkblfiqxYJfLUi3568P+adRROIivn+sfkced8jnI4zuPPBnM2jv+7WSK77CjiOE7jHFCPogwo A8pADRlQQVVDwjS7MtDYDOTmGVmwOCqM0tMd2X0XR0ZhlmnSp35rKJyOOFhkxyEiL74ebSGF2G47 ++Gb7xY5DHk6d/JFSWamI//8h8ghw6P5rW8Gym09QKRjh6iA6dbVkT69RHr39HOtw6zReX81wtmy w04ysmhJVMi99IaRnQ/w08bcHo1/7R0jux1kZKvBRs7EbFp+gZ92x1gDoWZk1AVGHsYsWlGRkatu NLLDfkZOOc/IJ1Oj/bBtVFcZUAaUgURiQAVVIo2GtkUZiMPAzO9FunQSiJmouGG2zAyR9FZ+AQqg YZiJOvd0kfGYgbI2kzNUEUHVq4fIvzCjRaHC2arCQiMHHeBgBqt8vSxLIcaZLe5bIlauNpgNM7Jx k8ifT/BrPxbH6t9X5KMJvpC74G9+/CtvGrn132jHA5j9elDkoSdFvptl5IuvjdwxVuSZhxCeLPLj ApHHnvHLfDBR5L5HRXbeAcuQR4lcfLXI4mUi//2PSLetRB58Iioo/RL6XxlQBpQBZUAZUAaaBQMZ PV1s6Wl4G/uwa4457ffHuux611xxgx+/8wGu+fRL12zOdU3nQa75erprlq9wTbv+riku9vNs2uya cY+5Zu/DXJPZyzW9d3DN86/+vl726ISzXMP+BcEys77387/7kWtOPjdadsYc1/TdyTXhsGv67Ii2 TIumPfSka5Ysc81Rf3bNxE+j8dfd6poL/uaakhLXtB/gmg8n+Wk//+rXkZfvh39a6LeDdTS0sb/N 4uTUTigDykCjM6AzVI1OuR5QGagZA8F9ULZkaamRDyeJnHGKSF6+kYVL/NmdrLaOnHSsP0vFclwC TEvzZ6DaZTlyyWhHpn3oyPyvRfb7A2erbI3lXc54vYu9VesW+vjxK8wUdRV5/lU/3z/vE/l0msjA XY2HP57mzyR9+Q1mzdJF9kfd1i48x5ENmNla+ovIQfvbWJHNuSKcNZuPY3TtjOXIg/x2Poi9Yqdj ObNNaz/cCrNwHdqLDOj3+5m0aG3qUwaUAWWgaRlQQdW0/OvRlYEqGeDyG5fzgvbMyyLtshC/oyNc EuTSW/t2vuDgst+EtyB4sOncLvfxl36fTI1OvvTF8uEZJ/vLhsF66efy3uo1Invu6osaCpv+fR3Z dy+R1FQ/N4/5Ptow/38+fsCxpuCYCxeL9OgW3TzOXxB+Ns3ILOTv1iUaX1LiC8KzTxXxliUD/ZuF je8Ub9beeE+X+ywX6ioDykDiMqCCKnHHRlumDGDPkpEly6KCirNRDz1p5HbsLXryfp8gzibZX/Ix Zo9hDmZz8Gu857CROyJUKLUmfebn539udH/0GcwE/SkaZ32sb9BAEc52BW31byLbIB7LbhBvmHH6 mbNRjqxeK7LXoeJtnGf8GoQ3bDTCWbQLrxLZlCvSGr9AXInyjKc9+bzICMxW9e7pC0L+gs9a2zYi 87C/ysXq24pV3KSuG9ItN+oqA8pA4jIQ+b6ZuA3UlikDLZkBzt7QBu/J/8ab/TlwH5G3IUiGDvYF DwXQsIAgYU7OUl05JjpDdev1gl/V4bEK7+MXdpgpKiwSGXmgyI1/Z+7yxqXC2PqYY9lywa/y/Fmm G67kr/RE/v2AkZz1Inf8w58t22agkbEPY6lxP38J8KhDRI45zMHynpH/POQ/+4p5uIw3fpx/XM5e Xf3XaBv++n8ix54hMu0bEYqr3lgWtDNt0VzqUwaUAWUgsRgo/xU0sdqmrVEGEpoBbmDm85mSxfhk dD5+oVPH3/9isDZ9WJuDpUHMOg0e5M9UBev4ZYXxhFAoFOWHM1Y8PvdD9egWjQ+Ws37OzK1d58+U Neazp/gA08KVgUbbBqmrDCgDykAVDFR+VauisCYrAy2ZgWQTVC15rKrbdxVU1WVK8ykDykAsA6HY CA0rA8qAMqAMKAPKgDKgDNSMARVUNeNLcysDyoAyoAwoA8qAMvA7BlRQ/Y4SjVAGlAFlQBlQBpQB ZaBmDKigqhlfmlsZSEgGFi428v4n/iMJYhs4d77/8M3Y+LqG+a6+ad/GP2Zd69byyoAyoAwkGwMq qJJtxLS9ykAcBp59RfCuvDgJiOrbW2Ti6/HT6hL7wqN4+OewutSgZZUBZUAZaD4MqKBqPmOpPUky Bl56wwhneQbtbmTM7dGZni+/MTLyeD/+kmuMhMN+2s13GzwQ08jJ5/ozTufjWVB8yOYdY4089qzI q2+JfP4/P/z4s0ZGXcCHYhq5H8KHTx+nLVhk5IhT8DyroUZOO9/Isl+MjHvMyD/uiB7/5+VGDv2T ET5mYfFSI388Hc+uGmzw8E4js3/w8/FFx3wwaGqq4+W7coyRvjsZ2f8oI29/6Odh2+59xMiw4T6e fzV6DL81/n8eJ155vrz5mpv9vvIVN+wLjfWOONbIC6/5x+Mxv5lhhHxsvZuRsy823kNB/dr1vzKg DCgDyoAyoAwkNAN8bEJt7eU3XDN0H9dMn+2az//nmo4DXfPtTNcsWOSabfdwzStvuoYvBd7tINc8 +IR/nN0Pds2eh7jmy29c8+wr/guD+QLkX1e6ptPW/guJt2xxzX5HumaH/Vxz9zjXrPrNNSw39QvX rF7jmn47u+aZl1yzaIlrDjnBNXxB8SPjXTPy+Ghf+MLi2+7xX6rMetiWdTmuuTrbNfsf5ee7817X XHqt7z/lPNeMvsw1S392za3/Rvv39OP/9YBrjj7V79d7H/svQGZbY62i8nzxM4/Bdn88xTVZ/Vyz bLnPEbm/6O/+S6D3OtTv/9Mv+i+IZhrz1cZYNqFPOm2cMqAMKAPKgDLQ3BioraAKh13TZ0dfANmb /kNPumbJMtece6lrXoLYsjbmdtdcfj0eIAqh1KaPa+b95KexDh4/Z70vZLpt58eXlPjC5cNJfpjl 2vZ1zYaNrrnkGtf89bpo3Z9Oc83bH7pm4qeuGbK3H09RNGh31+Tlu2b8C6658Kpofgq+rQb7YYqg J5/3hVr/XVzD9tAovCi2cvN8wciwNR6D4jFoFHrxylNEUVgWFUXzU6h9MtU1FKPDhrvGdf20k86J 9qu42DWte7tmbeC4weNV5VdB1dw+pdofZUAZUAaUgYRnoLaCikJm692igsDe5CmoKAYoMAYM89Fl G9f88z5/lme7P0TFxXzMXlGU0d54zzWH/sn3fz/PF0S2TooglqP46LuTa6Z9E63D5ln2i2s6YIaM dv6Vrnn0aT8/BdCMOdH8kz9zzS4H+mGKHaZdBrF31Y3RPLbO/zzkmnb9o/1gfygIFy4un7ei8jfc 5hrCGtvfc3vXzJ3vz6pRaFrjTN//vvPDs773Z+FsWk1dFVQJ/7HTBioDCcuAvssvYYdGG9ZcGViI 16/06Oa/E499/G2tkZ8WimzcLDKwv8j0SdGeb87Dq1rwwuGnXhTZfZdoPN+3Z18ozHfh2Xfv8d1/ wRcl27RNqHsNXuXSq2e0Du51OvwgvoZG8CJjke9mGfl2hsiDd+GFxsjPlx933yqa/9V3RM4/S2T9 BiOr1uC9fIP9FyIfOjyaZ/psIx3xahke97LzRcb8zU8Lo/7CQr72pvzLGfgqmnjlZ6D8kSOj9U75 HO8u3NZ/f+HM7438Be2gbdps5JdfRXYa6od5XMuLH6P/lQFlQBloHAZ0U3rj8KxHUQbKGGgPgbRm rciGjQZCxsiFV0EY5Ipk4UXAfH9dwRb/3XhvfyhyyAkUXiIzIRSsaGJFFA5WOM2ZJzJkG7965gsK Cq/cTiKt0gG8kJjCjfbMS0beeNc/Dt+3N7CfyOV4gfJNV/sbzdPSRIh5P/n5lywzMhmi5uw/+8ce CjGVnu5I+yzUucjfKP7rSiPnXirSsQNeatwWguwX1uWLtUuvEW9zPGv7erqRRUv8rUoVlm8tMh9t xQyTlJQYuQcvVv7bxX5b2Pdh6BNtNjbb812CmZm+UKMQC/Lk59L/yoAyoAwoA8qAMpCwDNR2yY/7 i/Y53DW9sIS16wjX/OMOf7mK+5AOO8nfp7Tj/v5G8cVL/TTmn/J5dJmLG8q51EfjMh2X83751TUj /uiaDyZG87Ec9x3Rbr7bX1LcY6RrjjzF32juJeDfiWe75sBjouUYf/2trsns5ZqDjnXN9vu6xu7L +veDrvkLjknjEiKXJZnOzeEfTfbjf/jRNb138DfHs23cYM79XbTBe7nmxdcrL89lUW60514pLumx LTQuT3Lpz9q9j2BD/OXR8AFHu+atD6Jhm6+6ri75JezHTRumDCQ8A+Xn3xO+udpAZSBxGODNd8uK 2n+EfllhpHcPEc4QWcONH7M3IikpXP6Lxtv0ityNm4x0aF91/pz1xpt5apdVdV4ea8UqI3n5IoMG sE3xyxQVGcnZINKze/l0PvZgIfrSs7tI507l04L9qKh8Xr7xlh0HYPasbZuKywfrqqtfX45cVwa1 vDLQchlonKtUy+VXe96MGairoGrG1CRt11RQJe3QacOVgSZnQPdQNfkQaAOUAWVAGVAGlAFlINkZ UEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaSnQEVVMk+gtp+ZUAZUAaUAWVA GWhyBlRQNfkQaAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQB ZUAZUAaSnQG8GEJNGVAGlIHkYYAP/FyxSmQlwFf28MGj+UBeAZAnZtNmpxjvQAyzR5mtJJSRISmZ GSYVr94J8fU7fA3PVl1F+vUW6QsE36uYPCxoSxOcgXjPeIwXl+DdaFbN8993Vb5L8eLK56hBSAVV DcjSrMqAMtDwDKzN8Z+wvggvTl60TErxkuYteAFyeOVqCa3NkVZ4kbOTmSk5rdJkBR4sv8l1ZXO4 1GwqKpYNeAHzBscxecBmMU6KcaSVuNKKbmoo1Co13W2TliIZGa1CA1zXDCwslh7FRdJ6qy5mS5/e Dl7hLHgToZoyUGMGKJasYIr128psug2r27gMBMWT9dON569Vy1RQ1Yo2LaQMKAN1YYAvhV60VOSH H/lyZcf94UdT8OMCJ7xsucmEAApntpZfjDjzNm5yZ0qpWWlCZoVx3RXFhQUrZGPHjXm1OHhxhWWW Z65wt+q38rdQP1cMXk+tpgxUm4GgeOIWGoata/2sLJiPYbXGZyAonlwc3oatny7HycbXuIUsrKYM KAO1YEBfPVM90tasMzJnri+eZsyR/JmzJbx0ubRpnSE5aekyJzfXmV5YXDrfuGZBeMuWBZLbLqd6 NWsuZaBJGbAiiS5FlAXexOn56do0mxdRXhxdtcZhgAKJZoWSFVCckabfuvTbNJsXUdU3naGqPlea UxlQBqpgYBnmlWb9IDJjjhP+6luTP2eepJUUS2lmhizES5C/yd9ippe67pyS0Lof8hf2xK4nNWUg aRmwIolCiuLJYiP8TFNLfAYonLjMT1FF0CiqaFaI+aFq/FdBVQ2SNIsyoAyUZwD7j2TBYvHE0/RZ TvFX30nB3PkmMxSSfGz8/j53s/tZcamZXlxYPEPWt16+oXxxDSkDyc6AFUxWTPFeSqQBjsHmPrXE Z8CBoZX4qYqUAHZM2XCKK4ZrNJAqqEidmjKgDFTIQHGxkXk/+eLpu1lS+L/vpAhiqnVGK8lJTZVZ Gza5nxnjTi+SLTNkZTvdg1Qhk5rQjBjgzTa4xMd7KX4/6t2cm1E3W0RXMtBLK6YooCzs8l+1SVBB VW2qNKMy8HsGcvOMZLW1n8XfpydbTM56f7/TbOx5+naWkzd9lnF/XSmt27aRFejldxs2mS9KxZ0R Ltk4M/fnrnhogZoy0GIZsKKKS32cmeJMB2/OasnFgB0zCim7j8ou+9WoJyqoakSXZlYGogx062qe 7LWDc/rO25vC449yso4YaUJDtk0OccVnOf24QGQ+MG+BUzJjjimYMVvSC4sk1C5L5hcVOl/l55V+ W5rizipZ+fPcfNmmKNpz9SkDLZ6BWDFFQcUZqswWz0zyEcAxo4DiMl9QUNVYVCXH1T/5Bkhb3FIY 6LmydavSrQ7Kap9ynHHljxkZpvUxhzkhiKvMwYNEtu6PjRWpTfMxKykxguc3ybLlIj8DeERB8awf nIKfFpk0PBAzPauN87Mj5ocNm813Jmy+d0Kh+11TclTx6laYn1JTBpSBShiws1IUUZzhaB1BW7hf 6x4qsJAE5m+hkr3QVD6JhT+SIQoBPmWF+6rsRnV4q7amudJX3S7NoQwkJQPpPYqGpDipR3Xo6BwV LpHtCgqkS6+eUrDjEEd22VHaDh1sQttuLVgmxE9L2otgNkgiH+pq95cbwnOwyztnvcg6Ag8ZoH/1 GnEx61SwcImEf13ppG7caDLbtJb1eDTBL3ju008bN8pMbA/40TEl8wp/y1iGI0c3XHbN656R1npe 4Uqnc7n4ardKMyoDLYYB3jetoOIyH2c4KKjwafaAPYXRjxbi1BKUgci19wA0j9sXCAqqLQBn5K2g qvZgqqACa2rKQMMxsLBVWtd+Q5y00NBWqc6O2G+1J57sPSBcKll4snfbkhJp1TpTirBHqaR9O3Eh sNziEnHCeHFKaakjJWHj0IUgcqCjZPNmSS/YIun4JV1Beppswqbw9fgQr8GTwlfn54eWhEtKl0I0 AeFlhavfwbzUydX6hpXePXwyZqhOL1oZOrbhuNCalYFmwQDvm9wuw2U+OzvVBn4KKv4E/xMVVGAh CSwiqA5BU/moCwqqfMDOUlFQ8RVW1RZUuocKbKkpAw3HwDZFJWtlFuqfxTlkfmLLW3aosN0VHfJz W3VctTbUEe9KaRuGfsJf2AmZMH5HFHZKI27YhIvSijfIyv+s3yLZNV7fL3/c8iFHnP3FNZ+Xj9WQ MqAMVMIAhVXwl34UWIRacjFgx42zjnY8azXZpIIquQZeW9vsGIAw2py9vmizYNHOn2Nuii46xn2j sDAfS4JqyoAyUEMGeBPmzZjQe2oNyUuA7BwzO34cy1qbDn6tqdOCykDzYaDwt7TJzac32hNloFEY 4CyGhZ3Z4I1ZLbkY4JjZ8bPjWasZqjqpseTiTFurDCgDyoAyoAzUKwPBG7C9KdfrAbSyBmfAjltw LGt1UBVUtaJNCykDzYeBVt3CR7fqUXJY8+mR9kQZaFAGgjfeWL/eUxuU+gapnGMWO47BcLUPqoNf bao0ozLQPBlwUkLX4wEK3DOvpgwoA8qAMlBLBnQPVS2J02LKQPNgYGkGfhO8S9Hq1f9rHv3RXigD yoAy0DQMqKBqGt71qMpAQjCQ0b33H9CQ2SJ9+DA7NWVAGVAGlIFaMqBLfrUkTospA82BAVdC+xvR 5081h7HUPigDykDTMqAzVE3Lvx5dGWhSBooL8h6UzWv4dGA1ZUAZUAaUgTowoIKqDuRpUWUg6RnY 3N57oGjS90M7oAwoA8pAEzOgS35NPAB6eGVAGVAGlAFlQBlIfgZUUCX/GGoPlIFaMZDeM3xqq+6l f6tVYS2kDCgDyoAyUI4BFVTl6NCAMtByGHBM6BRjzK8tp8faU2VAGVAGGo4BFVQNx63WrAwkNAOO IwcUlxZ9ltCN1MYpA8qAMpAkDKigSpKB0mYqA/XJQHr3oqHGyAZZ12ZVfdardSkDyoAy0FIZUEHV Ukde+92yGXBSholj3mjZJGjvlYHmycCoUaMkPT1d2rZtK23atJFevXrJ5ZdfLps2barXDt9///3i YKr7888/r9d6k7UyFVTJOnLabmWgDgwUr0p9vmhlylV1qEKLKgPKQAIzcNVVV0leXp7k5+fL3Llz 5f3335fx48fXa4ufe+452XPPPeXFF1+s13qTtTIVVMk6ctpuZUAZUAaUAWWgGgx06NBBTj31VJky ZYqXe+XKlV6YM1eHHnqoTJo0yYufM2eOnHPOOXLXXXfJwIEDZbfddpPZs/Fmqjj2008/yYoVK2Ts 2LEyYcIECYfDZbmOOOIIeeaZZ2SvvfbyBNfUqVPloosukt69e8sJJ5wgBQUFZXmbk0cFVXMaTe2L MqAMKAPKgDIQwwBF0csvvywUOrQHHnhAevToITNmzJAzzzxTLrnkEsEvfr3ZLM46UXB9+OGH0q9f PxkzZkxMbX7w+eefl5NPPln23ntvyczMlIkTJ5bl+/777+XRRx+Ve++9V4YNGyYjR4708rz77rtC Ica2qCkDyoAykPQMpPUIn5HR030l6TuiHVAGmoYBTkSkA1lAN2BrYBgwAvgTAG3StHb66acbtsMi FAqZQw45xGzcuNFr2BdffGFyc3ON67pm5syZXr7NmzebadOmmc6dOxvMNnn5vvzyS7PNNtvE7cyA AQPM119/7aVddtllBsKsLB9mvgwEmRfG/iqD/Vze8RiBvVzm2muvLcvblJ4IPxwzjh3HkGPJMeXY coxrNOmkr54BY2rKQEtiICSOvhC5JQ249rVFMsBN6HZ2iRvTMzIyynjg8txxxx0nEFOyww47lMXT 061bN0lJSfHiuKl9y5Yt5dIZgNCSpUuXygUXXOBtSs/JyZENGzZIYWFh2XG4vEfj5vi+fft6G+QZ Tk1NlZKSEnqbnamganZDqh1SBqpiwNnfLQk/VFUuTVcGlIHkZYDLcJht+l0HSktL5bTTTpM777xT Pv74YykuLvaW42xGzGZZb4UulwXPPvtsGT16dFkezIp5G9+5R4pWnXrKCjcTjwqqZjKQ2g1loFoM dM/tKo70KFl7x5xq5ddMyoAy0KwY4EwSZ5SOPvpoT/Q8++yzNeofBdgrr7zi7bHaY489ysoef/zx 3q/9rKAqS2hBnqqlaAsiQ7uqDDR3BtKk1QAj5k6RbLe591X7pwwoA79noEuXLt7sEjeLE7NmzRIK Iz5moTr2wQcfSPv27b0ywfwUVO+9955gb1YwukX5nRbVW+2sMqAMKAPKgDJQNwY4EcHVnVZAa6At 0A7oAHCNbQI2WsNJbFu1apX30M927doJlwGxYT3uEmFi96JureNDSWEnATnARmAzkAfwuQ5FAJ8F Ue0vn7rkB7bUlAFlQBlQBpSBlsQAH5tgjZvQ4+23sunqVo8BXfKrHk+aSxloBgxkh9K6F++JX1Pr zHTjjib3q50WOeRUuD8DnNmwxpkOTml0AW4HPgVi7QVEPBeJtPVdjXBxBKVwCRu+Cf4/At5P4mPc 3/9sCxnUlAFloG4MqKCqG39aWhlIGgZa9bjhkBQn9W7BS/ySptHNs6FcHrqhgq7xHR77AVsF0vk8 nKMAiqqgYSy9Z+Uw/UFgfCB8M/y0uQAFdBCZTFBTBpSB+mVABVX98qm1KQMJy4Ajof0xYfF5wjaw 5TSMQuhCYJs4Xf4BcfOA4wJpB8PPB/d8EohTrzKgDCQYAyqoEmxAtDnKQMMx4BxgHPezhqtfa64m A8uR79/AuArycybqxEDaCfC/CtTmaYjtUe7PMdgNYbUWzsCoUaO8h27y4Z188Cff68eHgW7atMlj 5g9/+IP3ME7ureLG9Z49e3q/BOQGdj7sc/DgwYInpJdj8bDDDvPeEVgusgUFVFC1oMHWrrZkBuam Y+fU7kWlOdNaMgsJ1Pd70JZBwPFx2vQS4kYAHYEU4FiAS4G1MdZxfgz2rU1FWqb5McBHJeTl5Xnv 8Js7d673YM7x47ly7NsjjzziPbMKr6URPi5h3Lhx3jv7+NBQvvz44YcfFr74mMZ39/Edfg8+yNXn lmkqqFrmuGuvWxoDXfp3MeKeJ791z29pXU/Q/vIn2fx6PxYIblBnc5cC04FjAAqywJgAACAASURB VO6nYt7aziwuQ9mDYnA/wmrKQDkGOnTo4M0uTZkypVy8DQwZMkT4DKvIowZkr732kr///e9yzjnn yA8//ODNXj3++OPSqVMnW6TFufrYhBY35NrhFsnAujYr8fOv2s5ytEjKGqHT7+EY3Et1fZxjcay4 7Edx9TJgADVloMEYmD17trz88svesp89CF5sLHzvX1FRkTczxffzjRjByVPfbrrpJu9hnhRXfJ3N kUceaZNapKszVC1y2LXTyoAykCAMXI52XBCnLa8gjpvRTwLqIoS5ZMgpg1jwV39qLZwBvs+PM07E rrvu6r3E+NRTTy1jZc6cOfLRRx/J5MmTvZch8+GfixcvLkvni49HjhwpBQUFctRR/CFqyzYVVC17 /LX3LYSBVt1LL8JkR/R18y2k30nQzUVoY7wluNWI/x/ApzZz+a+2th0K5sRBVm0r1HLNhwFuQl+3 bp2H/Px872XJfK2MtYsvvth7Px9nrr777jtvBuqBBx6wyd6eqYceekj+7//+T6644gpPWJUltkCP CqoWOOja5ZbFQFrP4mH4CnqJyIDCltXzhOntTmgJf7lHGw7YB3QyTLsB4IzROgYCNhL+wYGw9Qbr s3F/hWe0DUTct+Gy3njYHJNXgy2QAW4u56/4iIyMqr9vDR06VLg0SOOv/c477zy56KKLvM3pFGI3 3nhjC2Qx2mUVVFEu1KcMNEsGQiblAGzB+axZdk47pQwoAw3GAPdOcTmPs1dvvPGGjB07tmyf1L33 3itr1qyRm2++WfjqGs5U3X///TJjxowGa0+iV6yCKjFGiN9Cuek0Dega8T8MN2ijEJgciVgAFzMO 5YxfL3KBPwLB+r5G2L6Ogsfgs2xseAf4+W2Z8bF4BnFqzYIBZ3+jD/RsFiOpnVAGGpOB0aNHe8+o 4rOq+MypQw45RK688kpvHxVno7j8x2dY0fbZZx8544wzvOU/zl61RNONiYkx6hRA84F0gG8sXwNw 38NhgN0/QUF1LnAQcDOAp157fjieHYP/TwPdgQGArS/4MMBViD8L+BiwRkG1EGCdas2QgYwe7prC osLdZH1rPlBSTRlQBurGACciUoFWQGugLdAO4LW7MzDBGH4/VUt0BiKPgOAPP3i/3QhwKZz7FgsA Pq4kDLhAtYwnhlpiMnALmvUg4MRp3ouIwzKON5tlk0+A53WAs081Nf3015SxpMm/NKPUCR+uYipp BqyhGsova0OAvoBe9xuKZa23RTNAla2WmAw8hmZxNukc4MmYJnL26XuAT1B+HOA4cobqFKA2tiMK /Tmm4CSE18bEaTDpGBhQWLJSmnpTw6+g7QiA52x92n9R2UOAv0vWnzF4IuYATJ8GcDbhCuBAYDFw J7ACoG0LXAzw3XpTgHsAfitlmYrq4xea84Gg8fNaCvwd2DmQMB1+PsCTxs/saQDrHw8EZ4sR9NK4 7H8fAxGrqH1Mrqq+nZCHX874jXsJ0BvYG3gJuAPgt3A1ZUAZqAcGVFDVA4kNVAUvzNwn9SbwRpxj cJaKs1IUVLy4c2aKN4Pa2G4oxKnqoP2IgAqqICPqry0D+6Dg6toWjlOOXx6I/wNeCKQPhJ/7AscE 4n6O+P8Fd3fgWoDnOz8r2wMUTW8DE4EbAC59U9BcDVRW33Ckc4ngQ8AaRRKNwuo2gEsHNNv3A+F/ BOBxKOqeA/glaBowFDgeoOij2LHG5aSK2ldZfSzP51jhcRkeT/lwdwZmAh0Blr0XuBBQUwaUAWWg 2TAwGD0xQHBTenqkd0/DfRAYBUyOxNHpCxQC7QE+GIQXR2vB+mwc3VXAocEI+HlRvzEmToPNhAE8 f2qcdC7o1UjdOQDH+QCgEH8F6ADQ3gS2BvYDeJ5yBoj7uXg+9wesvQ/PdjYQccfB5TketOsRGAts BigMrB0ND2d2Yy0FEfzC0SeQsAb+Q4ATgf8F4llfDsBlsYrqY/ZngNjPEuMdgJ+zePYyIv8WSODn 1rb3SPjZp+8AxlurrH2V1ccvy98AHIPOAOu9BLgT4JcltnMqkAHQeA24COAYrAQ4TqyD1hN4EVgB fAxQqNE4+zUeuAZYAkwHdgYqspuRMB+YBXAMrfGcORP4GmCbhwMPAb8C3MbQGog1juldwBqAZc4G aBy32wD2ge2luGZfabU5jl+y/H8eIx3IAroBWwPDgBHAnwBsoVJLBgY4VpEx49hxDDmWHFOOLceY Y11tq1HmateqGeuTgWtQ2anArjGV/oLwt8AfgeMAXvDUlIEoAxBSTsg5VXJa88bSGDYOB/k3sCfA a8vFAG13gDfFTsClwEaA4moBwJufNX5BcG0g4vIGlRkTdwfCnMlZHxM/CGFeED8HeJO1x+8Lfx6w HLC2CJ5tAZbhDd4aZ47Yzi5ARfUxL49DEcCyHwJ7ALQeQBh4FfgeeATgjBCNZWKPtY2X4gsZ9mlK JGydytpXWX3s208Auf4z8DbwAPArQOHCGwn5Y19pzE9eKVIOAQ4FjgRoFGIUibsCzwCshyKlDTAK oOA6HPgZuA2IZ7xZHQGcAJwCXARY8bUj/OcDlwMzgYnAFuBoYDDA/LHGseUx9wVuBCjAyBXrPQzY CzgIOB04C6DV5jh+Sf2vDFSDgdRq5NEsTcvAahyeF6l/Al/ENIUi6iaA+yB4kayttUZBe2G1dZTA k2sD6iYfA+mt0g/Aj40+a6SWp+E4WwG8AfKY5wLtgFiz5zNv6H8DlgIhgEKKN9u62AAUTgd4g90O uBXgZ4MiaRMQtF8RoCDoD2wGrFF8sm1Mq6i+x5E2EPgK+C9AwTIJGAr0B9oCbwIbgDHASwBv8v2B YDuWI8y8lVl/JFbUPqZVVN8gpC0DaCcB5JpGsfsB4AD8Fr4SsPY0PJ9GArzeHAW8DbwHzAbygR8A cmvbzeNfCZQC/waeAmhDgAzP55dhvtOARUAngDzvBrBeGseKfKYAZwO8ruUBHwPbArHG8+tuYGEE F8Dl2I8G7gPILe1B4FTgKYBW5XGy2+CX0iGZBIJ4Hrj4Z8AWz0+3LA7PIfESwSPcEDI5Oa7M+W+B xxWPo9YCGUhtgX1Oxi6PQ6N5ocDnuZxNQIgXD36rrItdg8JE0D5C4PBghPqTiwG8oWt/3As+b6RW U4CfD/wH4Pn4KnALEGu8ofJeROMNmjcq3qDnAdbOgccKgC7wTwXCwPvA1UBFdhkS+Blh/ZMBih7e xK8HOgNB45cICq1uQDAtE2H2hTfkiup7HGk9AduPL+Cn+Dga4IwUBYNNWwv/1wCPUQCwP9bawEM+ KjOWqah9ldX3K8odF6mYwo7H7Q3sBzwAXAd8CgSN4sTaUngs17xPUCAOA34AgvYbAhRTtDyA/NFe ASgwaX2ALQCF7gnARsCKLXg9Y3tpxcAvAOuihYE0z1f+X38EfwxEPRPxM558W1sCT1cbgFvlcbLz ZXV2FtroyD4sF3vR9eIQyfgQA7DNrrzzdIE8D28HL0L/tUgG+EFRa3oGfkIT7OeWF2Drty3jBd5e nGwcXeaNd7EJ1hfM3yMYiPhHwSXUmhsDxtnflfCTjdQtzg5MA7YBdgIoYm4HTgOCxlkRa1vBQ0Gz 2kZE3E/gUuzQ3gB4888B1gCV2XAkcsaDAoJGUdAP4A2ax6XQ4TIXbQAwF+gF7AJY6w/PAoA38uFA vPraI343gKKNRvG0DGAbKQ55n50H0JYBFD4UFGwH22OtPzw2n42LdX9GREXtq6w+Cp8dAc4S3gZw LBYB5wGctfkf8DcgaOTIGstSLKUALwAcg0MBjjP7Ys21nhiX5YM2DoGOAM+PzcA7QNAqqieYJ+if j0DwenYIwozjmPYGLK+D4efMl7XqHudpFPAElS1YkbuxFA8Qz5dnka5iqiKSWkg8P/hqyoAy0AwZ KFoV2rFkVfp3jdQ13rhnAhQbc4CXAQqYWNseEQTtDICzDFbknAp/Z4CzCJ9FUAyXN0SGecOszE5C 4n2RDF3g8ovCa8BK4FvgXIB2MsB0Cgze2Hnj3BZoDVwLTANoFdVHQcEbKGekaHsAuwEfAN2BSQB5 oBi5BPgIoKh6Ezgb4HWXwoLts8eCN65V1r7K6iNvdwNPAUuAwwG2ZSqwFzADoJgM2gkI8Et2W+BE 4AuAIqgz8C5AMcIxq41RaFIoU0xRzO4LOEBNbG9k3j1SgLycBrQCKKwogDYCbCfbmAGwfo4Rj1sz y8UMm8FsGZb2KixopCgnLBdCTD1YYR5NaFEM8MOjpgwoA8pAXRlYhwreA1YCXHKhYLkciLVliHgF oNjgTe90wNoL8PCmmWMjaujeg/wUUJxVGgR8CvDGSzsbmAxcBFDoUTCEgaXA1cB0IA9YDQwHaBXV R7FyHXA/cDswBGAdLD8VmAhQXLKPFE/HATTmPxhYDnQAHgaYtzKrrH1V1TcBFa8F3gQoqhYAvYH+ wIcA2xE0tp95MoF5wF0AheBTAPtD4TsNoDj9N/AUUF17ABkfAUYDpcAzwA0Ax6u6djEybgK+A8YD FLDsF8fxTiAXeBb4GFgEsD90PwKqbTe2wab8kHfupkGSUZTFs/XrXDl1XIF3rrWNl0HjWh4DFZ0s LY8J7bEyoAzUBwP9UQlvyD/GqeyPiKPIGgn0BygWDFDf1hcVFgJrYipOQXgbgDdZ3oSDloVAV4A3 6FirqD470/QLCmyJKcT6tgLYRzcmjfXx5r8hJr6yYFXtq6o+isiBAPtnZwSDx3sOgS8BCh3OrlEY B42zQPnAZoA8UhDmADUxnhfkmHzRyE/sGHkJNfjXB3nZVoo0a3ac2dbYftg85dzzsXWiV5Y3Y/g3 SKjtvUTMQMHPGTDfOFsFgYUTdhE2oB87Ls8TpK2RSEHVDiAnnQF99QxISAar71fPpCZDp7WNdWKA Fxx+4Hlh501GrQUw0KqH+6brhu8s+S3960bu7rJqHI8Cgzf2hjJ7w46tnzfd+bGRkTAFCRHPKqqP /fgpXgHE1aa+CqryoutaH0VUPCEVe0yKJiLWVgUiyGNNxRSLU3QGuayrmGKdy/kvxiob53JZs7nM 205GY2bhKiTwWkmJvwL/H8w18gQunN87DoRfREzB/RIDcRzEFMVaVGyxnFqLZ6AhBdVYsMsp13/U M8unoT5+y7F7JVj934Gd6YnYdLg8Pu1YgGV48RsPcDqYxg/DFcCBwGLgToAfJFpF9bHME16O6L+H 4J0GHADgi045OwuhUmBbgNPV/HY8BbgHYHus9YLnfuBEGwG3svZVVR+/Ld0OsF5ewEqAg4FlAPvG /jaEHYlKlwHz4lTeEOfD3jgOx5T7M9QsAz1X8lvzoSW//XyKjUoQl+Lj6QRpizajPAOvIxgUO+VT m1kom18ys+QSCKkr0TXeT/gchB8gnv5pcuVlpHszmNlt8Xw/B7/29GemXszJlXPG+dfThrx3sjlq SchAQ54Ut4IPU4+cDEVdxwMUQS/F1EvhchtAAUfjPgjagQDX7blWTxHxHMCbDAXQv4DdgWuB3YAp AKd6KT4qqm8g0nYAxgDWfo54hsPdCHwYCdOhaOLs0NvARIDtuBngB/hqIAsYBZwBDAKCVlH7KLQq qo/leby3gOuBr4BdgVUAx6MP8ARwHMC21reNRoXvAvEEVX2fD2z7DGAkPS3dWnUL/xEnW5eS31Kf zCjtujf2gICbbYoSjBcKKkIt8RigoGr2lo0ZKSdLLjWYkYJ46uJ12MjXCN+Rnevtt4M3YC6WQENy GSJvz97sTQ4wPRTIoV5loF4Z4En5X4A3bc4M7QXQ/grwBkubClA4zAIWAMGZGN74/w8IGgXGIcEI +Dn7wVmO74AHAGv4klHjVz2koEwxQIFhbQ08PGZl9R2N9MdsgRj3GYQPjYljkH39XyD+QPhzAH4o ewLs04sAj2+tsvZVVh/L3wNQeNIeBjiDdjfwPrA/cBlwKmDtKHi4DLIcuB/gPgfaTsCnAOOfAtoB tCuBi4AJwArgZSADuBTYACwDjgUuieB5uBSgwfOhF8IfAeuB14GdgbMAil9rHeD5BmgP9AAo1DYB PIeGA7QdgBc8n7+v4y74ySPLnQ1YOx8eijyC7Yhn5DxeeY7TbcBKgP1lX3iO0D4AzgS+BnjM4QD5 /hVgv1oDjWKtuoePyujpmrTuxXtm9CzNzuhReicPzHCjNEAPogwkMAO4OLW6uZ1cdnOWrIZrCDxr 6nNsQD+4qmYjH6/7QeM1IR3IAroBWwPDgBHAn4BkeOuKthEMcKwiY8ax4xhyLDmmHFuOMce62laj zBXUegHiC4CdgCeBRwHaAKCf5/N/uXM2/DzZOEvzOMDG0ihsSjxf9N8e8G4XDXq+9/H/CmBKTDxv tmHgVeB7gDfljgCN5PAGbG0xPNsAfYE8YDlgbRE82wKV1TcI6azzc4A30IsBa4znzZXH4ywV+0Bj mdg2dEJcF2AlwD79BwhaZe2rrD7WcSDwFtAd2Bu4CPg3sA/wFbAG2AqgcXwoiP4OHAqwzRQc7YBJ AOuhCOMYPQPQ+gB3AC8BpwK8YZ8EUDiRE/I/GaBougVYB/AYwfOB4fkAhdRC4AmAouRsoA1Ao9Dj ebUJYH6ObX/gNuA1gP3jSc8ZOBrH4nBgX+BG4CGAXFHcXQeQ51OAC4HTgVirqDz5OwzYCzgIYNmz ANqOwPnA5cBMYCKwBeAFeDDA4zWOhcOLDD5HoVDqc3C7hkvdKendS19MCaV+ndG9hBcLNWWgxTGA C1MKRNR5Xdp515l78VWoG26hX5tSOQQzUvvfku9d5yrlBfnerTSDJioDEQZS64GJXqiDNzfag8AU z/f7fzchiqKFoPA4AOANiDf7uthAFG4LvAlsAMYAvNnzJtgf4A3Z2nJ4mLc/EIxH0JtV4M28svoG ID0d4A2bgu9WoAh4HGA5Cpb/An8GKEiGAv2BzYA1znLgnlcmHGx80O2PQEXtY1pl9aUh3QU4k/UR QKPomQyEAfI+FqCNAiYC7zAAuxToD5wMLAGs0Lse/pUA+aG9AlDU0Mg7uXgWyAfWALkA7VvgMs8X /bctvHsDI4FCIBuguP0pgkPgss7jgReBbQCKJIoU9vtVgO08CpgHWDsXnruBhRFcAJdjdTHA89Jy cR/87N/zQNAqKj8amViG5w6NdZ0KPAXQeA5w3FOAswGe5+zPxwD72ihWtG7Vz6169AvhYD3xvWtd SkoKeUqB//Wi1WkVfSYbpW16EGWgKRjIbit/wrLebeJ4X2541Z2NC+8YFUhNMRot45j1IahuA1Xj gVXAF8C/gOCNDkHPeKOztgwe3iR5M7fWCx570+sBfxHwF4AiYBegIuMxOwH4rHi2Fv8529EZKAA4 E2StDTyLAM4iMD1orRFYDFRWH8WBA/BYFCgUUacBjwM9AdsG1nEUQBHANgSPlYlwCWBv0PD+zipr Xzfkrqw+N1IbxeUwgDdZCoifgAOBQcACgNYf+JGeiH0Hl/gnwNkXiiNrrMcel+LKGkUUuYtn0+NE 9kfcUoBiisa+UpTQOBN1DPAhcDDA8d8NmA8ERSTF3lbAPMBaf3iCfXkmksD+7gFcHQmnwWV9sdYf EfHKM57nkzUeu6sNwP014i+G+wtAMUXjectjNZINAJ9uPm4g7cRxrsVJmo6zcW1hSc7ZjdQAPYwy kBAMcBkvJcX7kRE/97wqL8QXixuz87zri71GJ0RbtRHNiwHeJOtqpajgcICC4jWAN7K2QKxxGcka b9arbSDi5sC9KIKpcCdE/JfCrcy2Q+KQQIZl8BcAvFHzBtcPsNYfHt6EGZ8FUIhZGwDPXKCy+oYj vQNgjcKA7W4PjLCRcPmhXQYw7WegP2CtPzwUNLzhVmSVta+q+r5EpRRzbwMO8AbAmaZdgeuBCwFr FBAUr9a2gWd/YBPwMbBVAH3htyLQijZE1dgoZlhvSqQkRceoiP8VuGz7YcA0gPxxTNjGEGBtMDxf 2UDEZb3BvhyCcB+AfbkEsH1hHh4j1ioqz+P3DmSOPXZduAhUWy9eT+hi0NNxAykQU3qKrOuaWy81 ayXKQIIzkN1ads9uJ59ATE1EU/fAZ2Al5uovwK/2hkJMvYQ4FVMJPobJ3rzgTaq2fXkaBY8E1gDj AQqFDCDWTo5E8IbEbw72hsiZKs6k4Bt22esmVsC/KBL+HG5l1h2JkwCKGt6kefP8CCgAuHR0NsB+ UiyMAnij5o3nW+BcgMa2cSaLx6ysvpOQfh9AY37W9xpA8fYscDRAY/84s/IB8A6wD7At0Bq4FmAb KrPK2ldVfbeg4hsBiszzgGOBWcBhwDXAjoC1d+E5GOgHpADsWzdgCjACoIiinQZMBaq6IFFcZwKV 2S9IXAr8KZLpLLjHRPzknzM+NwMvRuJ4LiwDToyEKZI4lrEckhe2sxVA0cTzciMwGTgF4DlJjAf+ BtD2Bnb3fP44xStPjs4AWNYBOMafAIloS9go3Ei24P8LhbrUl4hjpG2qZways2Q77JN61UmVb/EB HYmL1EZ8Bq7blCuDbsqT/2ZX/uW1nluj1bVkBlLrofP3o44JwGwgC3gUWAfE2v6I+B7gDfGfwByA djnAm+xMBmphU1FmIsDyFAUh4DiAxrZRMCwHOgAPA8xLOxvgzfYioBPAG3YYmApUVN89SHsNYF+5 lPQpwBt5MXAdwOPdDlDMXA3kRUD/9Ih/NdzhQFV2NjLEax/FSGX1UdgeA/wXYH9+BDjOWwObgTGA tQXwUDDMB1YBc4A3gFJgHLAQWAy0AUYBVRmFBseWfazM2IYXAHKVD1BUWXsZnpuBN20E3NuAZ4Hr gZ7ALQA5DxqF0gcARQX7fSdA/nkMjhF547nBsbsg4r8Y7iZgBvAU8D5gy7MfbNtzwEfAIoD10f0Y YF00iiz66dJsvB/6fdjG179rSn80knIEGrKpMDz/ijhtqf9j1qxGEyd7vLg42TRKGSjPwA0Z0i8t TW7E+X4WPn0pOJEwKyv3F+bK3fjwbiifW0PKQMMzYG8CdT1SR1TQH5gHFAGxxrheQDrAGxhvVPVt WahwK4A3Tjem8r4I5wKxH7IUxG0D8CbJm3DQqqqvEJkpXoLGmynr+wXALEE5Y31dAd6wq2tVta+q +jhbsx1AIbUMqOjm1QlpFFEcm6B1QYDjRlEWK2CC+YL+tgiw76yvMuO5wPpXVpYpkEZRR1FI/ihs Yo3nMtEboDi0fbXnOMvST4FYmbE82xQ8h+y4kkfWnZDWqkfBxY6T8Z+wmzMivLrrtARspB0TNs36 6cbzJ2DztUmJwACW9nriK+INOGtGY88g9wqWGEeeKA7LLXcUNMrnk9cRfknl9ZWrDrzmcUsLv7Tz Wvqa/4t8+NQSmoHIq2dORCPXAxsBXuN5fykAqFuoC+z1Cd7Kzd5sKs9V91QrqOLNXNW9dq2hJTPA c9iexxQ+9FvX+slPMB/Dzc7SOnw6yKR2ah9et+P0BO1cUDxRsNqw9VsRa+MTtBvarKZg4Po20i09 5M3OXwQhlYFlPZ4vL4SLJfu2oiq/KNVnk3ktsYKKWxysoGoPPwXVGyqowEISWERQHY+mUlBxQsEK Kk4K1FhQ8aRoDLsNB6HiU1MG6pMBK5KscKKQIjizZ12bZvPy+PQ3OyvZeCBn1gh+a04ks9/wrFCy AoqzmPRbl+NiRRXbb8vRr9ZCGfBmpCCkIKLOxyc3E2cFz4sJYSM33ZZX7pe5jc2QPZ/p8ry153Jj t0OPVzcG7PWH4xcc0xrX2liC6tYat0wLKANVM2BFkhVPFFIEp26bpWiqmpKky8ELGJdKeFEjaFZU MU2thTKQnSH9saB3FW5x53FGyhNSRt4Iu3LzrfneXshEYcYKKZ6/3hIRZj70+pMoo1N5O3iN4ZjZ 64+99lReqoLUxhJUFRxeo5WBWjNgL1hWTPFcJtIAR6fca81roxaM3Hi4F6WE4xY4OC9wDKuoCpDS ErzZbfDcwRTMSBnv19f8gsRzYAKE1K0QUt8nEAdsF2/AVlDxHCZOAbj8x31V3PvJGeMMgNcmXqN4 zVJrPAY4PhRNHBvufeZqGfdxc3mPy3x23HjNseNZq+uOCiowqJaUDPBmywtTUFClI8ybs1pyMcCb jRVTvJBZ8OJWqwtbcnVfW5tNodFWjsO8zkU4E0ZEGCnBPqnncQbchaebz0swloLnqJ2Z4k2b+254 0+a1iGKQxvOYP+qxcSqoyErjGfnnGHEMCO6PoqCiy7Gye6XsTJW97tT42qOCCmyqJS0DVlTxwsVv fxRTvDmrJRcDdsx4AePFzCK5eqGtrTED2Zn4VW6anI/ZqNEQUj1YAU6CPPx7DHMK/8neUvYmghrX 3YAFrJiy5ytv1vaGzZszb9RWTNl4iileoxhvvzzAq9YIDHCcOA6ciaKgoogKiiqOGePtOAYFFctW 21RQVZsqzZhgDMSKKV6seNGq6sGiCdYNbU5kzHgR4wXNiinrKkHNjwEHy3qHYG75QnyIj0H3UjyJ YfBWBINnBebJs9n+ckyi9zwoqHhDpljiPdXeV62Y4s2b1ybG21l1eNUaiQF7LeEMFMcpKKq4/Gdn qayoYv4aCSnk98wOvA2rqwwkEwNBUcULls5QJdPoRdvKGSo73U6XNx39Fh/lp1n4stvKDhjVUVjW Ow0d6sNOYUmPN7EJkNEPZ+d5b8pgdDJYUExx5sNuPbDLeTyPOfPB65IVUxRcKqhAQiObFVQUuEFR xfGxs1U8D2P3UtVYVKmgauSR1cPVCwO82VrYCxkvVlZU1ctBtJJGY4BCmBc0XuDsTceOL90aX9hQ Ri0BGBiTJYPTjPwJD948GUJqp0CTlnrLekaewP6o2AckB7IltDdWVPFcpfEGbgUVZ87tUp8VUzYf 86o1PAN2nDguFFVWONG1y310GWa6zlCBBLWWxYC94VpBxS8HBG/OasnFAMeMyyIcv1hBlVw90dY6 eG7UbhjJoyGYToSI4qyU9+0HdzU+PPGVUiPP3ZrrvYszmYWyvUnzOsSb4tzUFAAAIABJREFUsBVJ jGeY4Llsz2k9r0FGExnHxI6XHRsKXvqDM1M2zs5osUyNjIOtpgwkKwO8iNlvfbxg2W+Dydqfltpu O272psMxtTeolspJ0vQ7m08Kz5KRaPDRGLQjMXI9vMb7I7gBy3pvIW7Cys3yyaP+LEDS9K2ShvJm yx7y5mvN3rQZx5szz+fYc5plfGbgUWsUBjguFlYsWWFF185M2Tg7pixTI1NBVSO6NHOCMmBnqXjx 0nM6QQepkmZxzII3n0qyalJTM3A+vrj0zJI9cIs6CDNQB6E9+0AilM0M4y70C+Lec0vlrdX5MrkZ iahY6u0NN3gDtjdse02ieKI/KKRUUMUy2bBhO050CY4RXQoo+q1rx87mQ1LNTG8+NeNLcycWA/Yi ZS9a9iKWWK3U1lTFgH6Lr4qhJky/FMvoHbJkV9ws9kMzRmA/1P74wLW18yzeO/WMTEPcu3j45rsJ 9vDNhmSON15rvCnbmzVvzPbaxGsSzYb9kP5vCgaCQsmKKjtm1mW7gvlq1E4VVDWiSzMnIAP2QkWX Fy97AUvApmqTKmDAjltwLCvIqtENzcANmdInLUX2xnH2xgzU3ri7DIPLH3x4xkGCiJoHiTDZNTK5 OFem/lNkQyS5pTn25ktaeJOmWUFFP+OtBf02Tt3GY4BjZc367fgxPui3+WrkqqCqEV2aOUEY4IWp IqigSpBBqkEzOGYVjSfj7cWvBlVq1qoYyOaXjywZhIdqDsOs0y4QTcMglCietipX1kAgGPkegzDN ceVTuFOy82V1uTwaiL0Z87yNtXhxsXk03HAMxLuOxIurdQtUUNWaOi2oDCgDykBSMODckCF9U9Jl aMjIELR4KO7sQyGidoTrLd3ZOz3EFNXreoisr+H5CgLrq4J8+fpukdyk6GniNDLejTpeXOK0WFtS ZwZUUNWZQq1AGVAGlIGmZ+D61tIjPUW2xlzfQLRma2AQsB0BncQX9JZbgIqIqOUQTrMgrmbCnVlS IjNvL5Sfvbz6TxlQBmrEgAqqGtGlmZUBZUAZaHwG+Mu6rhnSMy1N+mDZrQ8W63pDBPWBCOoHYbQ1 /APKRFO85hlZhemRHyG2fsQC3jxs8vmxxJE5d+ZKTrzsGqcMKAM1Z0AFVc050xLKgDKgDNQLA9lc cmsl3UvTpRuW2bpjM1k3iKVuEErdIZC6QSj1QHwfiKFuWI7z9wfyN5EwpJfNONGP5bl1cBejzGIE F6PcYjwMaUFKrvyYLbIRcWrKgDLQgAzUm6DKzpL38IE/0mur4WcblwQYPuCeW0XYxUWA+dxIfvx4 JBKO1vW7NFTOX1NEwc2Tfh3ecyVQp+eizlLU5qWh3lIvjHxMpx+N9d3I8yjQDzzMFw9mQzzqi8Kv rxQ1hXFsGx/1I55lUSbM4yBPGN8mvTD9XjzTWR550KFoWqlXZxht8tKQ4rsIe3EhhIt9P8MGYZOH OlAPnkoWzgfwvBeWwaHVlAFloLEYyOYrj7KkXbhY2qemSHvInnb4vHfAtaUj2tAJH8jOcDsjTNcL 0894XC/4HkP/4WmILLOI33PwD+KI16lf4V2Ozz+X6X7FMZbjWvIL/Euwz2mx7nMqY089ykCTMFBv gqpc6x3BdQIf94CVCyC+2uHYiuKULTtMTKXlgpFAMM762ViaDZf5gxFejsg//3tiMMb3B+LLigbi mMmLj8RFvmj6ZcsFEBVvZMp+uOwXwWW7zDrAdzOAiy6FZwkO5Asy47u4eP8uDv3mE2IpHCkAfT/L RcqwnjKB58dF6/BFZVkZCMdoGutAerljIo55oCApQH1ERCOPkcK2hANpNg9jrZ+iEiIS7ygpXYKG z8PDIJeBUohJNWWgMgacbDxLCW9BzQy1lox0VzLx+coopZsiGSlw3RDSjLTBZ6INzsc2EDBtcP62 xWehDc4/btz24nCQtkjPQnw7fD7aI097lPFEUVrZoy3LNwX5ypkN00V5vu1+NY73G13UTfc3fH5W 44P8G9JXu2H5dcEWWTnB/3KHZDVlQBlIRAbsZ7s+2+bVmR3RDnMj7vYRd2XE7RlxsYDvQDuE2vvh EK4u1DehzEi4KEscXKc4fxUqNr4LXeGF0egQ48vcdN+P6aUUxkOjeC5u4im4gHp5Gcd0HgMXUFxL JQUZUzAlloKKvPxIo5tqEI8LXQouasyfArHiuagptcwP6WP9mDVKZTm0h/KI/hTm9VxfIvlpjp/P O46Nj8R55RjHsF+H78aLi58H1bYwwywmeszZOgyFlBbjxtmpcxcJpWLQUzAEdAEHAx2Mc5iW4qcx nxdmXuTz0/z89HvhQLxNjxfvhELecb1yTsSPOC9s0xhGmo1jmbjAicBPhJcWcW3Yug4/MYE83ugz DoaSnst0LxxxY8OGzNHgBv1eFOmNF884F7+oJ0oxCWz9dE2cuEi66+XFRG04LFdfdZVsnSIvZjhS lB6SEny2S/EeGhcnvcEHkq3l59b/DPBZSMZ7HlI6ulXez1kipvnPS7L+DMRloBJP8Hj9a4h/Bl88 RDbh2JvR3k2gZZPn+s9m4vvrcnAd4V6l9ciXg+tPDi48OXh74fpsX1A1RKu0TmVAGWhkBvyrbCMf VA/XcAycBDHXHeILIhSrD5IaypJUzAyl4lt5mndj4s0pXVLx7dwPU6hBbkI18n1qviBEGALTS2cd EQEZTUcctEC0PMVnMMwyTqC+QBg3lt8JRNyA/LrjC0Q/vy1n87DOSBxumDHzgA3Hr9acnAzgHCvE OVmI828LXYQ9Nyacj3OKyEMeTnzm4dzKR14vDjNG+fgSlo/PTi409qZiVzZtyZfNY/0XOycnMdpq ZUAZqDcGVFDVG5VaUSMyQAFFocVFFv4cvC3+dUJEJwjArlgSfDZn3VpvBoSzIZwJIQxeLub5I3Gc VXFL/TRv1sTmRT4/zc/vzb4wLRBv0z03Jp4zNWX1Mc3O3KCOsrQqZnHKyuDu7s0Oefnhj7hMLxeP u75XBi7jaf7EHT2RcMT9XRhZvFkuFuKckOfAtX6oC/rL8vgZvHDZrBpn8YKzbJXMvnmzgZHZwn/d cw8ekCSvpTqSlwqxkgbRAhQgvCXVlcKQI8WAt7SMJpRg4qsIzSnGklix59LP3YWhSLgk4ke4MF+K MDW1JVtQhnSoKQPKgDLQgAyooGpAcrXqBmPgd4IKR+KOMm4l48bfCWXLVgioJS4DEZGGiVVvSYy/ RNsM5AHcW0QhxL2AUI9qyoAyoAwkNgO6VJLY46OtSzAG1q5dK/PmzZMtWzAPpqYMKAPKgDKgDEQY UEGlp4IyUA0Gpk+fLttvv73svvvucuKJJ0qnTp3kpptuqkbJirMsWLBA3n777bgZvvrqK9luu+3i ptnIbbfdVh544AEb9NzCwkLJysqqsF5muuKKK+Qf//hHuXIaUAaUAWVAGVAGlIGWxwC/CPAhEllA N2BrYBgwAvgTgBW/+rOVK1eatm3bmueee66s0mXLlpmtttrKPProo2VxNfW88MIL5vDDD49bDMLI LF++PG6ajbzxxhvNiBEjbNBzIdBMx44dTVFRUbn4YCAnJ8esX78+GNVkfo5VZMw4dhxDjiXHlGPL MdYvfSBBTRlQBhKfAb1YJf4YaQubmIH77rtPDjjgADn99NPLWtKvXz95+eWXpUuXLl5cfn6+jB49 Wvr06SMQOfLNN9948XPmzJFzzjlH7rrrLhk4cKDstttuMnv2bJk/f77ccMMNMm3aNLn00ku9MOsf N26cDB8+XBYuXChXX321V0cpNrNfc801AgEne+65pzz11FNe/KmnniqfffaZcBnS2uuvvy4nnHCC pKeny8cffyw77LCDtG/f3ptV++03PuJIBMJQXnvtNc+/YsUKOeyww7wZN5Zj22gV9cdL1H/KgDKg DCgDyoAy0CwYaNQZqqOOOsrcfPPNlc7iQAyZ4447zmB/lXnxxRe9WSLOBEEwmdTUVPPXv/7V/PTT T+b44483Rx99tDeDNHbsWAOhZjgDhiVFbxaMM07vv/++V27w4MHeMSHozE477WSwRGg++OADk5mZ aSC4vLRddtnFPPbYY56/pKTEdO7c2UycONH88ssvpkOHDgaiykBwmb/85S/miCOO8PJdfvnlZsyY MZ5/33339drG/BBwBoLPi6+oP15iPf7D2agzVM3iI6mdUAaUAWVAGUhGBhpVUO23336GoqYi4/JZ SkqKWbp0aVkWCqNnn33WE0YUOeFw2Ev78ssvzTbbbOP5g0t+FFQUXuvWrfPSKMSsoNp5553LLTc+ /fTTZu7cuV4+zHyVCaVJkyaZHj164EkOpeb2228vi2fG1atXU7iYTZs2GSuoKPBCeLwtNth7dRUU FJhbbrnFUAhW1B8vYz3+Y5sALtPqkh9IUFMGlIHkZUCX/JJ37LTljcQAl+q4STzWIEjknXfekSVL luDxUK63HMdlOeLrr78Wu8TWrVs3gUDximMvVoW/EOzfv79AfMUeRrBfS4YMGVIWf+aZZ8rQoUO9 8J///GeZPHmyQCgJl/tOPvlkPOk9JBB3XntsIbahTZs25ZYHWe+AAQMkI8N/kDhmvrzN6ixbWX9s neoqA8qAMqAMRBngwxHVlAFloBIGuA/pX//6F3e6l3u45R133OH98o9iB7NLnoihaKFt2LBBWrVq 5e1JosCpi/HXfqtWrSqr4pNPPvF+Acj9Wn379pU99tjD+1Xfm2++WbY3ir9I/OGHH8rKcK8U20Zx aI31rlmzRrhHi4IPS4bevrA//OEPFfbHllVXGVAGlAFloDwDdbvSl69LQ8pAs2TgwgsvlLS0NMnO zhYs3Xl95OMO3njjDW/DOWd5evXqJVjC89Lw6zxPaHEGqzKjCKvO86yOOeYYr278cs8TVmeddZZg f1RZ1dycjj1enoDba6+9vHjs0xIKr59//tkLs70jR44sJwgpxtj2V1991cuDpURvxq22/SlrkHqU AWVAGVAGlAFlICkY4BeBRntsArcM2b1PrVu39h6XwEcmvPXWW2W7ibDs5m0Ix2yVt7n8tttu89K4 FwozXGX58Cs607t3by/MPVesB78C9DalDxo0qCxfcA8VZpe8Tek9e/Y0EEHm/vvvL8tHD2aZvP1X +NVgufhzzz3X4Nd+BjNOBsuJZtasWV663UPFAB+zwEdCbL311t4xZs6c6eWpqD9eYj3+wzjqHqqk +MhpI5UBZaAqBpyqMmi6MpCADFBQlXuXH8IN/uoZ6AhvPxP3F3HprNy77dAAziBxVgrCp+xxClVx x2W24uJibzmuqryc+WLddj9WVfmZzqXCjRs3Ch8CWlE5Hh+b4b26g3XWpj/B8tXx66tnqsOS5lEG lIFkYEAFVTKMkrYxloEmEVSxjdBw3RlQQVV3DrUGZUAZSAwGdA9VYoyDtkIZUAaUAWVAGVAGkpgB FVRJPHjadGVAGVAGlAFlQBlIDAZUUCXGOGgrWhADeMhmud7yl4PcH1WRVZUerxz3P/HZVGrKgDKg DCgDjcOACqrG4VmPogx4DPABoXymFY3v4ONDOvHrPjnwwAM9Fy889tKqkz5q1CjvnX18WCifMcVH N+AXfJ6Q4rOl8Cocb8N7WYXqUQaUAWVAGWgwBlRQNRi1WrEyUJ4B/jrwqquu8l50zJTrrrvOe4Dm okWLvKet83lQTzzxhPfE8+qkMw/ry8vL815mjNfRCN4DKOPHjxc83sF76TFfyqymDCgDyoAy0PAM qKBqeI71CMqAxwDFTpcuXbxX0zCCr3jp3r27J6oYxouO5ZlnnhG+goZWVbqXKfCPD/vkQz6nTJni xZ533nmCdxB6T0IPZFOvMqAMKAPKQAMwoK+eaQBStUplIB4DeKin9zwom3biiSfKFVdc4T3b6ogj jpCDDjpIDj74YJssVaWXZYx4WP/LL7/sLfsxqmvXrp6YwouXy73XL7achpUBZUAZUAbqzoDOUNWd Q61BGagWAz/++KP3qheb+aKLLpKPP/7Ye2XMtdde672X79hjj5X169d7WapKZ6Y777zTe8Aon+e0 6667enVwlsoa92cF3+ln49VVBpQBZUAZqF8GVFDVL59amzJQIQN8ijpeO1MunZvRueeJLy+eNGmS UHTddNNNZXmqSucmdD7lnMjPz/cEWvv27cvK9+vXTzZv3lwWVo8yoAwoA8pAwzCggqpheNValYHf McCXIdtHJvB1LxkZGbJ48eKyfMOHD5fRo0fLggULvF/nVZZuC2VmZkrnzp09MH+s8ZeEfNmxmjKg DCgDykDDMqCCqmH51dqVgTIGdt55Z+Ev+mh4abG3r4m/wuOv/2gFBQUyceJEYb6q0r0C1fi3bNky 2X777auRU7MoA8qAMqAM1IUBFVR1YU/LKgM1YGC//fYrE1Qs9thjj8k333zj/epv9913lyFDhgh/ qWefRVVVelWH5sM9c3JydIaqKqI0XRlQBpSBemBAX45cDyRqFY3OAL8I8BeqrYDWQFugHdAB6AxM MMbASSzjHqcdd9xRZs2aJe3asbkibCcfj5Cbmys77LCDpKSklGt0VenlMscEJkyYIB999JE8/vjj MSmJE9SXIyfOWGhLlAFloG4MqKCqG39aumkYSEpBRaoeeeQRb5P41Vdf3eDMjRw5Up5++mnvCeoN frBaHkAFVS2J02LKgDKQcAzokl/CDYk2qDkz8Je//EUGDhzY4F3cuHGjULTxdTRqyoAyoAwoAw3P gM5QNTzHeoT6Z6DGM1Tc+B12S6XURNyyMOLK/G7A78cH89NfGqmDZSoMI83FUl6p8evw/Yzz62c5 66cbTPf8OAYXLG1aPJdLgczr/ZXz++UY76VH8lg/h4Jp1pDsmY2zS6XRsOA5V34eR/AXCfj+aDx9 TOOf70cYfyEnBATdoD8k944dK9K3w1uS6hRIasoWSQttgVskKU6hhEJFKFyMakpQZxhuqefST7gg mG5KJOzFh4rBQLGYiFvqlIgpRTgFCBejXoSLiqU0rVi2/FYs4xYhf4AQBNSUAWVAGagNAyqoasNa spUZPjxV+mPPUWsgHUgBQoADpBWneG5pepqklmADj4O9SWncn+TDmLQyv42jy7LBcDy/wZFCUr48 45xAHMPxygbjeKyK8hn0SCJtNKjXIG/YzWqT1dYTNBRRYQgcNWWgYgZMIdLiw8iWaJqzBeduPja+ 5eOcKxAJ+X7GuYhzgFBKPk48xEueOO4mCedvlrum56IOPQkrHgBNUQaaBQMNJaiC9fr+k3Apoq0d 7rvb5vruhkJH2nQNScciXJaKcevMCknbEke2hB1JyQxJBlynOCTFrR1JL/X9JZlwS3CrdlFHGmYr wiHoAN8VuqVASkjcEG7WEX+KA7+L+BDiS+GHG0KcCfiZ7iKO8czjpUfK2XhPELCc6wsBh36KhEgc XSsA6KcwYN4yf0RAxIbxFdrL6wsJ67duVLzYckHB4R2jAmECFkl7SzfOkqTidEjBjInnYvj9MOLK /KGA349n/vLpfh2M89PihL1TC8Rj+JmPxy7vZ5xfb3AGh/V5edFOfjiCaeVneXC6e7M+nAPCXwV+ lrGzRtbP84BlrCGLZzaO+WnRMKQDZrGiM1b+lBbD8Wa3ovn8MtHZNc6Y+bNxQfeKK68UGdjxWWmV ukXSMSOVnlqCj3SJpKe4IA3EhdigiLiPc47bz4Mxkc+Igx8qeAIbQpti20lHZyDqje/3viAgzoYd 74cN7HLDGaf9PCHmbMJx+ZRVC4RlI+LwaPxQjucal/71uP6sFyecIwWyXsZ+RVGnpgwoAwnOQPTK WteG/mPEe7hoHFnXarR8QzBg/CUSb0kksDxinPJLKOXSKyjj5/GXYMrlD9TLeLs840aWa4Jx9BvE 2zy2HhNTRzA+FFnewbqNN/WUj5WaDYUpsmFLKtxWsrGwteQWt5GikvYIj8/dlOsJJiuerFBoCHa1 ztozEBmXk1ADBAXFhSc28uBiBkiKAJ67DTm748jZw1vh96EZkF0ZkGwZkupm4tzEU1KdDN+lHzAm U4zTBiq1Dc7fNlC8cN1oWBAnTDf45amDn3EaAK4xWZ6yRSW1tALU8Rva8huO+xvq9P0u4gRhB64x v8pPOStkwlwuYaopA8pAEzDAb3X1b3YjBmt2nOhXWi8c+V5rv8oy3fPj66uXFy7DFfkxj44LCOqE a8vRjyubFxd0vRt2JM0TD8yDi7NDIeEdh4KCcXSBSLz1e+WZD/H0G9zUPTcQ5gW/LC3k56EwCMYx D8vavDbMfFYoOCl+ut0XwjxMKycyImLCi4OfLpFainwuj4F9JaUQHCVhKSoIy+pFYZng9Q2HblaG mUZv1iL2sQkUet6MXNtWmc2qw9qZBmPAyFNT7XJfQx3Ekav3xaM90tpLSmk7LAu2wyULrtMeV58O uB51BjrhmtQJn2e4gMPHf0TixGmN9AGIH4D4qHmTdwwikvHbdTVy44i1qGM56voVcb+i/uU41nJM vi/BtWGx3Pn52mgF6lMGlIH6ZCD48azPerUuZaAhGahIUCX0c6gakpBkrTsBZqgSn7qLhreVTsXd xKR2wzIoXEK6QZD5riPd0YneEFE9oawq/5JsDPZzOUuQF5DFHhzzk4QL58kdX3PGS00ZUAZqyYAK qloSp8WalAEVVE1Kf/0dXAVV/XGJmkKYCeuOPWi9MaMFpFBk9YG/HwTYQPgHwt+xwiMaswFp84Af Mds9D9tM50m4YJYKrQoZ0wRloBwDKqjK0aGBJGFABVWSDFRVzVRBVRVD9Zx+7X4dJS0N4qp0a+gv CCwZhBmrIRBQQyoUW8asQitmADOxtWAmfgM0Q/45dVk9t0yrUwaSngEVVEk/hC2yAyqomsmwq6BK oIH8+/Dukglh5TpDMdcFkSU7QGztAtHVPk4r10CEfQV8KU5omiw30yN70eJk1ShloGUwoIKqZYxz c+ulCqpmMqIqqBJ+IB0Zsw9mtNKH4cdAwyCw4Dq7odVbxbQcvy40mMVypmDz+0TZtPJLPDSVv9JU UwZaDAMqqFrMUDerjqqgaibDqYIqSQfy2v0G4vm/+0Bc7YMe7AtgNgvzWtaMwbOznM+xRDgRP57+ WG79YrZNUlcZaK4MqKBqriPbvPulgqqZjK8KqmYykJfu1U46tt4bS4AjsUQ4EsuFO0NsRe8vRn7G DNebmMV6Sz6D0Jo6lc8XU1MGmhUD0RO+WXVLO9PMGVBB1UwGWAVVMxnI2G5ct39XPG/rIDwV7hCI qyMhrnoEsqxH3Lt4PtZLEFefqLgKMKPepGZABVVSD1+LbbwKqmYy9CqomslAVt4NR/4xYk/MTh2H bMdCXA2JZjfrsDQ4AUuDz8qtn34VjVefMpB8DKigSr4x0xb7ezX4AMPYJ6Xrgz2T7OxQQZVkA1Yf zb1uv20lJRVvd3VOxfLg9tEqzXy88PFJcQuf0WdfRVlRX/IwoIIqecZKWxplQGeoolwktU8FVVIP X90bf/3+O+EF2KdjluqMwLIg30f4vITNf+SOqT/U/SBagzLQOAyooGocnvUo9cuACqr65bPJalNB 1WTUJ9aBT8Juq8HDj8CM1WgIq2PQOH7GsUpoPsJm9nvklk8/8cL6TxlIYAZUUCXw4GjTKmRABVWF 1CRXggqq5BqvRmktH8mQnnY5Nq6fC4HVxjumMd/jRc/3yJeYudJfCDbKMOhBas6ACqqac6Ylmp4B FVRNPwb10gIVVPVCY/OsxHtNTupfMGN1KTqIFz/DjFko4mbLrZ+9hJDrxSXmv3j31nhxidn65tkq E6db8eLiZKtelA5w9XjSXInFAM/bijald0Laa8bU6+cksXrfjFoTEVQnokvrgY3AZiAPKAD4pG0+ rygZB/MfaDefKM5ftl0MPAAcDEwGrL0Fz4fANIDvyusFrAasHQ/PU0A34O8A67sSmA/Q7OegxA/K T3B3BMhbeiQu6HAp7d1gRFL4z98tTbq1wQb2lBvQ3m39NhvsrXKulVumvJcgfeBY2PtprN820abb sLqNy0DwOmL9dOP5a9Uy3pTUlIFkZsB+IOjyG2sif2tNZp4bsu123IJj2ZDHa4q6KRbHAbsAVgDZ dvAp4hRDFFAP28hI+A24hYG4JfBbsbQ//BRI8d61x1/PzQOS3x6dTr6ekZOw3Df4wDMl5NwI7cIn s7+LxzFMxouer8KM1cwm6mhQPHHmnGHrWj+bFszHsFrjM2CvLzwyrzk2bP10OU42Ht6amQqqmvGl uROLAXvi0+WHgShNrCZqa6rBAMfMjl9wTKtRNGmyfIaWcj/QZcC/47T6RcRxps4KqjT4OaN0ClAb I4/Nyybws/3peDlpewirrhd6wsqRg8SEpsuNI56ScMF1jfy4BSuSrHCikCJSAq5Ns3k5JvSrNR4D 9rNgry281tBvrzvW5bgwzZotZ8NVuiqoqqRIMyQBA1ZI8YPhLRFhKUkvWkkwcGgiL1ocM46dvbDB 2yztr+jVF8ALwMqYHnJP0I1AZyAHGAHw8QGTgNrYkSi0c6AgZ7neDIST1zthLnm5Ty4f/rS0kzHQ J5cgfI6ktj5Rxgy/Rdbk3i/+rFZD95HXGMKKKAopgrORev0BCUlgvP50AOz1h022okoFFdlQazEM 8ITnyW8FFZcGCH6r5zJIO4CzAq2BDIDf+vklghdAtcZjgOND0cSx4Y2d+6PyAe6X2gTYcbOCivlr fDFDmUQ3LsGNBzhDdVpMYxciPAv4I8A8JwATAHJSGzsJhciztQ3wNA9BZXt071QKl6tkzD6Y1Usf 6z1uIeT8W7q1+z8Iq0vktqkTbdYGcK1gsmKK1xWC1xhH93A2AOMNUGXkizcfEM1rkB1THomfO4Zr dB3iCaCWOAzMQVP+CfAb7FRgAMDXNNgLIweeN6SuwBXAfsCBQNBYljekUYCtrzf8twE0foOi2Qv1 7fDPBN5iZIzxWJkxcYkS5IlOWDEVhp/ghly2Ox2wfWUefqu1cSoM6elBAAAgAElEQVSoQEYjmh0j jgGxBaCgosux4pjZ8bOiyo4vkpqV3YzecL/U8Di9sst+TyPtWOBPcfJUN+ocZPz/9s4ETorifP/N fQiCeN+LeN+Kt0EgajTiLRohmkii+f2jEoxR44lRMMQrKlHRKNEgifG+4hUVUIwaxYt4RggoGhUP EDkElPk/3955tRlndmeXZWF3n/fz+W5VV1VXVz/VXfVOdc/s6+UWbtDlhj41We0/UI/99tGIcIWm wU3kXD2i96tu1a+un5xc8PR7S+H8mqlOxpGsQ8X4whhta1gK8GGb/sRi3Im5hbBss0NVtlTLpCAr LGflKWwAg+/pYjUxPZ/JDd1H9MtvR3CRIoANF6zYHMtG3vhU/KrgRc+GYIUXPZMwMFkzOTNRhzMV 6WjDp0fS4+ZR1FYPCtBf9AOfAukjnKisU0WfkR79iAOW7WNtNhqbpTPhvr1SvFNwVrdomw8++wg0 eUrYylXg/LEPJz/rvpVWqPiwOVh3+RFJizb7abXqN3rQesVS+P2qcKoYUxhbcKaYnG0NS4HoM8Yc xp6gxmdhh6rGktXrDjhBp4obBY8EsqavDaff4jlY4R/zGXsqZNJ6JL/d2IO4AcJpYmDjmo7rOtKZ vHGoSI9PlYra6kmBGKBYhcJxyjpVrL7GKlU4VeFQ1VPz6v0wo3TE/xN7ifsyR2cl5VnBtwH/Jri+ a2udtWOXgp1ZFcRRa7xW+e7URclZe9ycNG/OY8DDdMdfkuyROybZvdfPkwvGPVlHJ1/oTOFQMcYs ryv6dXTajbIa+owxh/kixqoIa3TCMfHUaCcXrjcFpulIvG/BALtvkaP+VWmHiXCoDlX8doFTVVPj naMjC3bCiXu+IG152cw6U5xvLL0TYvH4j0EunCkcLjtUqFO/FoMTA1bWqWJyj9UqnCn6EWJgWxKH QtUst8Z5DRQ4T4XGPX2tYAV6SeypIjsfq7SRRdIbX9IFTzB29tXq1L664zV+6mcWmueeSAb3GpXM XXBacslT0+vgpLNOFWOMV6jqQNRlUAUrVIxLMT4xR9TqKUatdloGJ9xUDjlRJ/o7waA6TlwveDGV x3GsVD0gmIBWFR+LruJNsbrgUcL74nDxuMCy9VWmlH7kxzELB3heYh0eOy5nYThGsSoVnxAZ1GJw Iy3IOlO+7uu3M8P5jU+B4TgR4lThTEVIWgxu4YgpyWYFaqnAwA3bJJ3WOV2O1emaJzV55mZq7e+c 5I1xIzS6MonW1Bg/GE8YWxhvWOFoLzrmecIvpUuJBmD5L4PvoaZ+nocVc55oMB7Fh7uyP9h5hUqq LedGxw4SV4lxImtTtMEK0gHibUHZJ0RtbKp2+m5tdlxG+8QkzeDGoBhOEulsQzhbhOFQUS7KKmqr BwXok+iv6JtwmrIrU5EWjhT72KzAkinwh0kaFyedp28Djk6atRmux4D7aQT4Q7Jpr58lg3OD9I+X x9biADGO8MEuxhnmUxwsW8NSgD7DiaL/lmiesEPVMDr+fjXz5+LMIs29WWk89psibhFNZRLiPBnU mHzDSIvJmMk560gx8MUgaIcqFKufkH4Jon/CsSKMT4KRFn3KPjYrUDcKVH4bsI++Dcg3KH8vx2or DQljknN63ZHkFp2aDH1iStEDnd3rXK2hjkwuGvduQT7jCONKOFWxGl5QzJvLuQLRb+FMxVxR42bb oaqxZMtsh5N05BeLHP1Wpf1W8Hs+fFuvtsbF1KXIzjOUtrxObNGu7AQcE3YMcjHohTPFKdqhKtLR SzEp+okQ6CNCHCjiEUbfRTll2axAHStw/th7koEbPpR0Wvtk/dr6memL681aHCDH6mr9QM0FyaXj eJ2i0s7osWpapm3yk+SMXvskw8a9EVmZMMYaxlDPqRlhGkiUPst++K51s935tZau3necpCPyPlPh KtUHSntGrCt4/Fdb21Q7flJk505Km1UkfXlIYuINY1KOyZqJORwoBjsstiu3/HdZKJB1lMKpij6L kHZlyy2LdjbmYzJOdBBTBO9jZo17BVjdrS/j24gz8wfLxpfu8SsfAw5LTtv9z0mb1sM0Ohwlx+ok /QzwT/Qi+0XJgoXDk4v++XnSsuUANYR3MtfTG1Pjk7N69EkuGP9cvnExphCGdkzMtoalAH0W/Zft 0xqfBTvbrEBjUCBuBM6lMB7n5+s9lKj/8GIdcrb4Tf7QOE1Y1nnKxitzq//bX0X4ksYVmaKnKr5N ZpsPGpfltw9SyD44dDeIfwiM9yj4/aKeYrIYJt4TWKn62GdkWuKbP1cr+pTYQ/zsm+Q09mP9xfHf WJwgNhJjxaWC9mA/EYcIXo7lcT6P+3kkWlX7qqpPu6b/MeAChWuLdwT17SmmCs6N88VY4ebVgu+z sRRsV9WJ5nx4W1XwJRs0Pi4TP1jx+rcze2ydtGjxOzlVce6fJrkcP7twjBrT7esG5fSDtLmvDtXj QfqNPuFldBxUfjMQh5BV/jv8UrpUaACWfymdV2Y+FTj2LB4wTnH/8U4yHy5yoizzClVZMrlQA1CA iz574RdznoqlNYBTaxRNPF9ngdNQuPqR7bOanOjmKozjgRP0t4Idf6ztoYKBEfugMkidpWsUP0vg RIwWPxA4QDh8Owh9EyzpLsaKLQTOR6n6NlDeluJsEfZ2PtJLIQP0Q/ltAs6fyfde8aigHecJnIvT BG05Nw/tu1KsLq4VpdrHpF6qPmWlx7tHISvbT4vtxftiiFhXjBQ4MbR1adsLOsBe+YOgcWvBsffN xBVdBvbb8RN1VH4EtJce8dEne8iZQqPFrRn/yqr535PT9xiQ/O4JdGdMydJ88R281QAUoM+yfVgY zzWAc3ATrYAVaIQKrKJzwgFg0mZlaGeB/UIcm8Yqv616lOIvif8IPiGGMfGzYpG1o7WxdzZB8f0E q04TBI5HGIMhxy5mfGnjV5kM9rtOtBALBA5G2HRFOGZV9e2vfPYvZqOU+L0iGZzrM5n0norzqJ1B /XpxkggbqMhjoqr2VVUf9bD6heOJjRBXi4sEq0M9xCDRT2AHijFipPhIPC42EtiJef6iMBzI8xR/ Q9CP9FvYg4rgKNE3UwT7YluKv4qu4jUxS9AnEee4hba2Eh4WrCDcKbYR2Jri7+IzwfF7CWxrcbM4 Q0wStwv24VzeFtn+12YJO6d3T728/qHIFeWcXouS075DXTi83cR2orfoK7RAZWsICtBX+T6j7+hD +pI+7Shw+Lkvy7YaFS67Vhe0AlagqSrw/3TicwUT25/EHwXWVayfxpJkV4XHCCYfVmlwJBi8MByb hWnsmz87KrrpN5tpDIfgl2JsQToT7ZeCifTfghWplQTGYMnkGzZZERyG9cRsMU2EMRlvLKqqb0Pl U+d48aw4QYSR/iPB8Vil4hww9ilsQxelrSIGi6yDhsND3VW1r6r6tGu6KnePwjUEuh8vLhG7iacF juNqIoyJ5WOxZz4cnc/AsTk/n4YTxOTD47FDxQ8E9Yazs5XiZ4gBgmNdIdoLJqntxbvi9wJH6teZ +LmKFxrHwmmj7rdEOF2k078VYqi4Q3COWkFKf4uPSbG/4Lp5QtAG2nixoB1V27z5r8stWgnXqGTB tq0uSU75zmkl853R5BSwQ9U0uryzTpNBjoHbZgWWpgJMvBX5A1ylsF8+XhgweeK03CaeFHsIjAn4 RiK1tA20XwdxtzhdMBH/TWAV4jMieZumkLIVIpuuzXTSZ3Kuqr6uyscR5FxuFOeLYwXGfh+IgQLH 7TGxjqgQs0TYe4owaXOs/4k5AufjGrGzwIGoEKXaR16p+pSV/vjkIoWHiYdJkO0kxggcT3R/UIRx nLPERDFIUBZHBXtOkIZjQzkcFpyijwTn0V2Ena0IDg/XADpsJMIWKsIq4jwxNRPH0coaDi1O4K8F ffUbcY+grt3FMDFD3C5eEX0E9rk4WTwrOM9xgtWt+wUaZ9uizSLWtvUAPfJrJZoVydW6ZT69fauT k1/tNkRlipcrurMTG6sCLZfyiXEz3CD4lFCXtrYqGy4YJMIYGH4WG/nwxwq/EtyYJwhupLHiUrFI YAcJBga2aes/BFZVfacqf5u0VOWf5xVcJtoIBsCsXa2NpwR5vxQ9xWTBYPCewLYTDAAMXPcKJgAG KaxU+6qqr3LPync/jtQGgwjHYnBcTZwnGJiWhqE1/c15FNrSuh4YiPm0zABuW7YKDNXhuY/eF0+K iwWTbqExKYdNVYQJ8tFIUMg9Hg7AmorPF/8ncAK2FaWMY3YRuXwB7qN/iZXFXMFKUNgKikwSTOzk Zw2nhvu0qvoGKZ+JlGONEThRjCXXi7VEtIE6+oj9BW3IHqudthcKHAZsC/F3MUEwLnwq0CK7jzZT p4v2rV6QV1hfjHMzVI76mosjxJuip9hQ/EeEPa0IGmPvio8FemKMc2FoNlgcKmaKtiJrjDlhsxWh XTW1Cu0wRXyR35Fj4rx8T7whZomw/yqymnhNcO3FeXPdvCrCOLdWsVEibCaH6bgSed9OXqFNv+RX u6+aXPOvi5M5Id23izml8SvQcimf4guqf686PEZH1XWUOFowEGStlza4sR/KJHJTdRD3ikfFWQJn YlVxmmBAuUaQzuA0WvxAPCV6iWL1KblWL6lerP12EKeL7mKsYPBk4H5E/EmwDP5zcbDYU1TVvlL1 LdR+2B/EJNFHMCFxzueLtQUaMDiF86honRnn9iOB5oVW19dD1L+bIh/EhsNlqsBXOvq+AseFe2mU WF8U2opKmJ5P3ErhzQUFPtH28fk0HJd3xR0il08rFeDM4zQwsWJTxVzB9f6OyLalQtuUI52xpYv4 VGBdBRNxVfX1Uv7LAmcFmyKov5PgPhgjMNo8VXBOrcW2IqxCERwaZmLGNO6bU8XtIqyq9nE/l6qP /f8pGAOolzHlLnGuuFBsLxhvska/haFHC4HzVWhnKmElsZGYJe4TWWPsXVLDaVpN0AauKxwhrqmx gjGNfo7jbKL4nwVG2drbGTt10Q99jkxyzVonzXLqL4WJwmbNdfz8dm5RWx2lrR4JtlHvtktaNOuc 9N/2qOS6CehsswJLrMAvVcMrYoo4JV/blgr/mo8PVsgA+YD4n7hctBRYDxE3Q5qgPxuLs2MjH66l 8DLB4BuDcT4rHbi/FxuZ8DDFn8ls91ScgY2b8RbxKxF2pSLX5TdGKSxWXzOlv58vUxjsr4TYP5vH gLBArJtJpP17i33EPzPpayjOIMHAVqp9VdVHVbuKvxCRfV+MFycINB4uGIzuFGEMyg8LJhPStxHY CuJ6MU0wiO0ksK3FDeLX4r/iecE+TD5sfyb+kN+mHQPFOJG9HjiHCwU6PCuOEbRjgugswnB4DxH0 11DxP/Ge4NqgL7C7Rbc0Vjl5MBDTZs61XT6dNj8uSL9RrCiKGZNPsf25Fri+Obc7xOoCO1kwAd4q JovTRD/xpnhZ7CCaknEdcR9gHcSHgmuZ+3aIwOYLJmSMiXCOoH+w3cV2aeybP/Qj11Axu1iJV2Yy einO/dlJtBDnizsFdop4WnAtbSTeEnsJjGuQfOwIQbsZn3qJUvVdpbxRAuMcqftI0VpwjYYOOyr+ uUCPrgLnbmPRXrD/tQLjnvqtID1oqzhWqn1V1cd+q4l/CdpQaDhi3FthBypC39AX3Ftcy6HdMMVp W9gjivw0v0EbPs1sv6v4Zvk8gjfFLmJXwb2FcZ8xpmDZONvoT7sx7iGcKOxYcUsaS5IXFB6ejzOu fiTQnWP8W4RxfWTbPVXbO0dmLUOuH47VUTAOdBNcs71FX9EQ3sd2Gyvfj8vl+4y+ow/pS/qUvqWP 6et6NyZSLmImRJyjaWJjkb2BRmt7pugpthCviQMFtpv4Yxr75g/1jP9mc7EYg8P0xVIqnRKO8ZJ4 SMQA8mvFrxFh6yiCiNywE8SeIuyXiozLb/xTYbH61lI653e74JypeyWBnSTGCNrNAHiCwGLAqdyq /PuUAvJXFHRgGIPEq/mNUu2rqj52/Y0IbccpTv9gj4v9RJt8XEFqT+rvFYKB6ULBcTHO/y7B4Hik +FR0EfTrQsE+9POd4j7RWqABx1lTbC8+F2jyfZG9Hn6h7ZcFE9u+Yq7YUKApx8K4qElfQ5wonhO0 cRPxujhGYO+KrcT6YrY4QNBmJjj6f0XxkcD5qRBca3eLQiu1P8ecIfYWTJz0+QMCw1EgjzYfLBYJ 9NxJXCWinKJNwvroLOkztH9FDBEYOkV8vuIPCvp6pjhHhN2myKWxkQ9r4lCxy00Cx/5tMU10FxjX J8fF2ZkjLhFhmyvygWA/2rSnCCtV3wYq8KLgOqY++noFgf1IUBd5C8RJImygItwX7wv27ySwNwRj U5bnyZBV1b5S9VXuWTnW3aUNtD1f/FbcIq4Tq4uwAxV5RrwpaPt0sYPAhgn2CztIEdpPP3O9Xy7Y p7PgfuT+C6O+XUT2/uc6GZsvkI2TxPXRM593gEK0miTQcluBHSrQHP0+FGiAcQyuq7CLFcm2e6q2 d47MWoZ2qBqJO6b+517rK3qL7UQ3wT3RUTBeLBOH6rs6MBd1XOw4LUxi2RtotLavEGEMONfGRpGw h9LGF0knaUfBzZ41bm4GSPa7SswStGOEuEiENVNkkegqPhYxYCiaCjuBiKxUfd9R3gxxlGAgYEB5 WGCcH4MLehwvPhHHCjprisjardo4LZugeH/xqeiXTy/VvurqYwLYSqwhJuXraqGQ+toL9j9LYBuL r0RbNmTtBBPcSuJLUSHCxijCedOv1EWd2G7iP2mssu0P5uPbK8TxWjm/zX5MGthL4odprPIP18Pm 4mzxl8qk9JPpo/k45Qfk4wQnitCdAZzz5ZzuFmH0LTcLffCvSFS4imCSWyGTRrTU/mcqL+sYccNx I3KNXyauF2FcN3FenO+kyGhCIdfOdqJNiXOer3T6YC1R2AcldqlxMgNiN1FsQFxP6bSx0LieNxUt CzO0XV19qxXZh2NvIrinCo36NihMrGa7uvZVVx/9sY3oKppVcSzyqKuYDtndOC+0DCumQeQtScjE xrVSaFw7W4sOhRlLeZt+pU30IWMB1xnXe2/BeNNI3I3Gfxr0Vb7P6Dv6kL6kT+nbGjtU1d0wqrMs Y6IdJZ4QH4k/i6Gi0N7KJOBgFDoUZP9NbCmY+DmxVwQ2SDyWxor/4YZDHOxJ0UfsL+aKmNAVTQe3 hQqnCfIY2MO4QWMCLFXfNSrTRcSxOF8ma45BGxmMyEMTBqX+4kyRbYM20/ObTETGQPdXsZWg3U8L rFT75imvqvreVf7aAo2pG7jRSe8kzhC/EFiFoNwXAqPuIaK7YOB4VoShz/2Cdn8ovhLYbFFs0iBv qviESIFVaPv1TBrXD0bfoGdLcbC4WWAVgvSw/yqyamzkwwqF2TonaBt+J9B2ugjj3NBwTiQorBDF 9r9O6VkdOHf2i+Oja9gCRV7Lb6APN2VTsxk6YajO/lddgSXI/1z7QjF7p1ii0uivcPgLi9SmvkWq 5M3CivLbVdVXYpdaty/qw5F9OTaqCBm/uL+qM8aKrJbZ+6u6fWuSzz1V7FrhHpxYk4pc1gosTQWY VOrCmKTPFUwwJ4qjxUGi0PD6wpjgmJgK7UIlHC9+Lybn42yzQlHKOH7vTCYDwlTBRP62qBBhFYr8 R3wpGAzWF2EVijAZVlUfn2A3E2FTFcHxYXDpJTqLsCmK0AaOw7njiIV1VeRVgeNwq/hYoMnTIqxU +6qqj30fEv0Ejs5Qcb9oJW4T94gbREwchKuJFgKj3FHiM4FGtJN8WEeMEBiTxZIYx10zU8Heiq8r 3hJTxXfFnuJOgaEVxw/bRJGsVqTjDGXr3EjbPQTn8g8R50G4nsCpzlqp/QuPjbM6R8Sks6RaZNvQ FOJck3Obwon6HK2AFWg6CjSvo1M9XPVcJVhdeFCwKpB1HrSZ2qH6iwPRQRwmnhQYk1s4YC8q/oTg kxQTIXHAMSll85Rxk9g/X2BHhd0FbblP7CY2Fu3F6eIpgfF46BiBDky+OBLkVVXfGsp/TOB0tRAn iocFEwQ6XCEwVr6o7w7Bp6vnxE8EdoQgf5L4nthQnCqojzZCM1GqfVXVp93Sd5hwjFiF+qPYS9wo LhAcj3MIe0cRHL+++YQfKzwgn/aewv75dJydVwWOTFX2pTLbVVUgn0e/UHcbgRP0ZzFTYLeIiwQO 0wyB/V0cLdoKtKGvHxFZo8yeYn2BlvTF6mKs6C24zjCOO07kBM7RIQIrtT/pewvqxQ4Ujwr2t9Vc gSHaxQ5VzXXzHlagwSgwe/bs5KuvvkrbS8i2rTwFcC4mi6mCSfBxweOhXQUrEdhowcTGp/r3xWMC xwHDwZiWxr7500PR8d9sLhbDYZq+WErtXgJtrTpwunAc5ohLRNiPFKGtL4sF4iQRdpMi5L0taDfO G7aBwCFkH+p7QKADtrn4QLAfjsOeAhsimJgLoa6q2leqPu2WWnP9PUcw8eNYnCluFPeK3UXWcKA+ Fzh4tH1bgeGEfCxeE+SfJTD69d9prPLP1grQAasQH4o/ie3FWyIsez2spUSOhfboOFCEVSiCHkdG gsJ1BO14V3BN4eSE40baVgIbIXCI0flu0UJgQ8V8QR0cj+sLwznKXkul9h+pcuzP9T1FbCOwy8Tg NFb5h7q3y2/vpBCH1WYFrEDjUYCxlbG5o1hddBPc871FX7FcvXz0zjvvpHPLSiutlOvSpUuuffv2 uU033TR377331mk711577dzEiRPTOgcOHJhbd911c9OmTcvdc889ufXXXz83cuTIOj1eXVRGX+X7 jL6jD+lL+pS+pY/p62ViHHxLQWOKGQ7VzwUOBpPp0jBOfhMRE232GAi0QTYhE19P8ZUy2xGtrj7E LyY49a0WlWRCJnceGbbMpJUTLdW+cuprpgN0FTgAbao4GP1XrF/YB4dplSr2LcxqpYRwJAvzCrfX VQLnUY7F+RZrZ3Z/Vkc7ZRPycc4BHTjXqqzU/mtqp81Eue2t6hjOswJWoGEqwJjPGNKgHKr58+en PohWi3JDhgxJnauFCxfWhV+S1vH222/n4hgdOnTIvfnmm2n6gAEDckOHDq2z49RlRerD5dahqu7W CIequnLOtwJWwApYASuwvCrQoB0qHJIxY8Z87VC9/vrruf79++eGDx+e69mzZ+qvPPDAA2mcVaYf /vCHuY8++ihNv/TSS3NXXXVVrm/fvrm11lord8QRR+TmzZuX5h100EG5SZMmpeWbN2+e23HHHXOX XHJJbtVVV8117do1d9NNN6Xllqc/usAarEN1qBq/w/J6h7hdVsAKWAErYAXKUKBBOlTXXXdd7oYb bsjhFG2xxRa5Cy64IPVtnn/++RwrSr17987hSC1atCjNv++++3Iffvhh6iCdffbZadmTTjop16lT p9ztt9+ee/zxx3MVFRW5UaNGpXnxyI9HjG3bts0999xzuenTp+cOOeSQ3HnnnZebMWPG8uRLpW1R X9epQ1XTR09lXGsli9xZMscZVsAKWAErYAWswFJT4JFHHkm0cpRoRSmZNWtW8tJLLyVyntLjffHF F8ltt92WrLzyysncuXOTESNGJD169EgWLFiQbLjhhskzzzzzdbu0KpUcdthh6fbBBx+cvPFGvCZd WUSrWgn/O1rOVrLKKqskHTt2TLRKlXTu3PnrOhprpD4dqsaqoc/LClgBK2AFrMByrYAeuSWtW1e+ PorTtO222ybjx49PHR6cH5wprF27dsmECROS4447Lvnss88SPdpLHaI4ObbDVlhhhdQBi+2mHhZ7 obqpa+LztwJWwApYASvQaBXQN/3SFaSXX375W+eIk3XhhRcm999/f/L+++8ngwYNSlecoiCrXLbi CliZ4ro41QpYAStgBaxAo1Fgzpw56WqS3mtKHSYcp/322+9b58cjvG222Sbp1q1b8uWXXya33HIL vwPxrXJO+LYCdqi+rYlTrIAVsAJWwAo0KgX0G1QJj+jWWWedZPTo0cmNN96Yvh9VeJKHH354MnXq 1KR79+7Jlltumb5L9eKLLyb6PanCot4uUIDfKLJZAStgBayAFbAC5SnAQgTvH/Mbfe1FB7Gi4K1r XkS6rTGs6EyePDnRD3ImLVu2TF9i5/0rfXtPp9d4jJfnZYeLT8RMMUvMFnMFP+T8pah8c1+R6swv pVenkPOtgBWwAlbACjQxBXjkF7biiviLtuoU8CO/6hRyvhWwAlbAClgBK2AFqlHADlU1AjnbClgB K2AFrIAVsALVKWCHqjqFnG8FrIAVsAJWwApYgWoUsENVjUDOtgJWwApYASvQ2BQ46qij0h/61L+d Sb/9p38dk+hfy6Q/5sm57rLLLgl5/OAn71Dxg56nnHJKon+unP7a+iabbJL+RlVWl3322Sfp169f NslxK2AFrIAVsAJWwAoUVYCFCH5yvKNYXfD29nait+grlrv/WVesQfzT4zPOOOPrLP7X3kYbbZS7 7LLL0rSdd955sX9orH9Vk9M3/XIPPfRQmq9/R5Nr1apVbuzYsen2tddem1tzzTVzn3zySbrdEP7Q V/k+o+/oQ/qSPqVv6eMaLTrVqLAqt1kBK2AFrIAVsAKNTAH+1x6rS3KQip7ZZpttlv5vvvxPDSRy uJJTTz01GTBgQPLKK6+kq1fXX399wu9dNVXzzyY01Z73eVsBK2AFrIAVyCvAv6HhV9F57BfGr6nz a+nz589PHn300fRHQXv3ZjGn0s4999z0X9TgXPXv37/oL69H2aYQeoWqKfSyz9EKWAErYAWsQIEC w4YNS/9PH6tO22+/fbLeeust9g7UxIkTk4cffjgZM2ZMMmXKlGTmzJkJP/gZxo997rXXXum/tOnT p08kO7QCVsAKWAErYAWsQLUKNJp3qLQalfv4449T5s2bt9hrT4XvUJFJ+RNOOOHrcnK4cu3atcsd d9xxuYqKipz+X+DXeQ0hop72O1TVXu4uYAWsgBWwAlbACjUiw0MAAAaYSURBVFSpgJyh9Ft8fJOv nH8rs/nmmyc8GsT4tt9Pf/rT5Pjjj09GjBiRdOrUKRk8eHCVx2vsmX7k19h72OdnBayAFbACVqAW CvDu1Ny5cxOtPCV33XVXom8Afv2e1OWXX55Mnz49Oe+885IWLVokV199dTJ8+PDkhRdeqMWRGscu dqgaRz/6LKyAFbACVsAK1KkCxx57bPobVfwe1aBBg5K99947Ofnkk9P3qFiNuvLKK9N8Drrbbrsl Rx99dKLHf+nqVZ02pIFUlv6r5QbSVjfTClgBK2AFrMCyVoCFCL4h30a0Fx0E/z24s1hZ3Kb3hxTY lncF8j8Bcbja+YmYKWaJ2WKumC++FItEWeYVqrJkciErYAWsgBWwAlbACpRWwA5VaW2cYwWsgBWw AlbACliBshSwQ1WWTC5kBayAFbACVsAKWIHSCtihKq2Nc6yAFbACVsAKWAErUJYCdqjKksmFrIAV sAJWwApYAStQWgE7VKW1cY4VsAJWwApYAStgBcpSwA5VWTK5kBWwAlbAClgBK2AFSitgh6q0Ns6x AlbAClgBK2AFrEBZCtihKksmF7ICVsAKWAErYAWsQGkF7FCV1sY5VsAKWAErYAWsgBUoSwE7VGXJ 5EJWwApYAStgBayAFSitgB2q0to4xwpYAStgBayAFbACZSlgh6osmVzIClgBK2AFrIAVsAKlFbBD VVob51gBK2AFrIAVsAJWoCwF7FCVJZMLWQErYAWsgBWwAlagtAJ2qEpr4xwrYAWsgBWwAlbACpSl gB2qsmRyIStgBayAFbACVsAKlFbADlVpbZxjBayAFbACVsAKWIGyFLBDVZZMLmQFrIAVsAJWwApY gdIK2KEqrY1zrIAVsAJWwApYAStQlgJ2qMqSyYWsgBWwAlbAClgBK1BaATtUpbVxjhWwAlbACliB QgVySijFosLC3l7uFaDPSvUn6WWbHaqypXJBK2AFrIAVsAKLKZCdiJmY7VAtJk+D2Ih+y/ZlrRpu h6pWsnknK2AFrIAVaOIKZCfgmJS/auKaNMTTp8+i/7J9WuNzaVnjPbyDFbACVsAKWAErEAowGTMp w5ci10ym0Lb8K4ADRZ9F/9GXtTY7VLWWzjtaAStgBaxAE1aAyThWNpiQF+b5gcJOYkWxgmgv2opW gjnXT4YkQj0afYTTRP98IeaKOWKW+ExEv9GH0Z/0bY3NDlWNJfMOVsAKWAEr0MQViEdDTMCxMsWk PV8wabcWLQRGmQUi0uxQoUr9WfQRfQDzBA4VIX1Fn9F3sVJF+ehfRcs3O1Tla+WSVsAKWAErYAVi siWMyRqnismayZmJOpypSMeZYoWKdD8OlAj1aPQT/cBKFH2EE5V1qugz0ikDWYeKfcs2O1RlS+WC VsAKWAErYAW+ViDrUDEh4ywxp8a8Gs4UkzcOFemsTnmFSiLUo+EgAStQ9FPWqeLxX6xShVMVDpWy ambR8TXby6WtgBWwAlbACjRdBbLOFCsfOEk4VOEsxeM/HKlwpiI/yijLVg8KhEOFg5t1quLxLA4v zlThu1Q1Wp3iPOxQoYLNClgBK2AFrEDNFCh0quJRXqyGMGHzmC8e9eFIQZRT1FYPCkQ/0S84VeE4 EcbjPkK2s4/8tFkzs0NVM71c2gpYAStgBaxATNI4R0zC4SSRzjbEI0DCWJ2iXJRV1FYPCtAn0V/R N/ECenZlKtJiRYt9amR2qGoklwtbAStgBayAFUgnaBwjJt+wmLRjhSrrSMXKlB2qUKv+wnCosv0T jhVhrExFWvSpHar66yMfyQpYAStgBZqwAjHhZidg4oADhUOFA5V1prTpFSpEqEeLfiIE+ocQB4p4 hNF3UU5ZNTMvPdZML5e2AlbAClgBKxAKZFecwnGKMJwpymbLxb4O61eBrKMUTlXWwSINy5arTCnz rx2qMoVyMStgBayAFbACJRTIOkyF8djF820osWxCHKWwiGedp2w8ytUodAfXSC4XtgJWwApYAStQ rQLF5tZiadVW5AJ1pkA4UdkKi6Vl8x23AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAEr YAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAV sAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAK WAErYAWsgBWwAlbACliBxq3A/wf7XtEbk5hacAAAAABJRU5ErkJggg== ------_=_NextPart_001_01CA9B99.79DB2F7B-- From bernard_aboba@hotmail.com Fri Jan 22 11:52:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21513A6A33 for ; Fri, 22 Jan 2010 11:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_20=-0.74, 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 1yz+l0S5UDD5 for ; Fri, 22 Jan 2010 11:52:17 -0800 (PST) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id DF67B3A6452 for ; Fri, 22 Jan 2010 11:52:16 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 11:52:13 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 22 Jan 2010 11:52:11 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01CA9B59.557C3B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqbnGMwPxe2xMSbRO6KRKVs9N5EUw== Content-Language: en-us X-OriginalArrivalTime: 22 Jan 2010 19:52:13.0160 (UTC) FILETIME=[6430BE80:01CA9B9C] Subject: [martini] MARTINI Virtual Interim II Agenda - Take One X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 19:52:21 -0000 ------=_NextPart_000_0079_01CA9B59.557C3B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim II January 26, 2010 9 AM - 11 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: TBD Agenda 9 AM - 9:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements (50 minutes) 9:10 AM - 9:30 AM PT MARTINI Requirements, John Elwell (20 minutes) 9:30 AM - 10:00 AM PT Invited Talks Solution Updates (30 minutes) 10:00 AM - 10:15 AM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (15 minutes) http://tools.ietf.org/html/draft-roach-martini-up 10:15 - 10:30 AM PT SIP Implicit Registrations, Presenter: Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration Wrap-up (30 minutes) 10:30 AM - 10:40 AM PT Discussion: Participants (10 minutes) 10:40 AM - 10:55 AM PT Hums: WG Chairs (15 minutes) 10:55 AM - 11:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0079_01CA9B59.557C3B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim = II

January 26, = 2010

9 AM – 11 AM = Pacific Time

 

Conferencing Details: =

 

Slide = Presentations:  http://www= .drizzle.com/~aboba/MARTINI/Jan-Interim-II/

Jabber room:  = martini at jabber.ietf.org (Please join)

Dial in Audioconference = and WebEx details:   TBD

 

Agenda

 

9 AM - 9:10 AM = PT:  Preliminaries

     Conference issues/debugging

     Agenda bash

 

Requirements (50 = minutes)

 

9:10 AM - 9:30 AM  = PT MARTINI Requirements, John Elwell (20 minutes)

 

9:30 AM – 10:00 = AM PT   Invited Talks

 

<Note:  this = section of the agenda will involve 10 minute talks by MARTINI WG participants, = providing their perspectives.   If you’re interested in giving a = presentation, let myself or Spencer know ASAP>

 

Solution Updates (30 = minutes)

 

10:00 AM – 10:15 =  AM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (15 = minutes)

http://tools.i= etf.org/html/draft-roach-martini-up

 

10:15 – 10:30 AM PT SIP Implicit = Registrations, Presenter:  Hadriel Kaplan (15 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-shaken-impl= icit-registrations

http://tools.ietf.org/html/draft-kaplan-martini-stirred-domai= n-registration

 

Wrap-up (30 = minutes)

 

10:30 AM - 10:40 AM = PT  Discussion:  Participants (10 minutes)

10:40 AM - 10:55 AM = PT  Hums:  WG Chairs (15 minutes)

10:55 AM – 11:00 = AM PT   Next Steps:  WG Chairs & ADs (5 = minutes)

 

------=_NextPart_000_0079_01CA9B59.557C3B00-- From spencer@wonderhamster.org Fri Jan 22 14:38:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4F03A68EB for ; Fri, 22 Jan 2010 14:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 omMvKSR1KvEq for ; Fri, 22 Jan 2010 14:38:45 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 596723A677C for ; Fri, 22 Jan 2010 14:38:45 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmbBD-1O7W371D1P-00a4lk; Fri, 22 Jan 2010 17:38:38 -0500 Message-ID: <891B9C8196084752BF028A061665FE4B@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Fri, 22 Jan 2010 16:38:31 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CB0_01CA9B81.54ED1330" 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+6yp7jUg5mTjNEoOImKFrmTNMNL6T9Hth+qgM df30oz079s85p77rvPcBsIJg5CqsVrAFQ4qU1D0fXVbgODNd1O HzcWGAoNDdwUyJfH05A1coatK3CdXbq9pjGGvHHewc= Subject: Re: [martini] MARTINI Virtual Interim II Announcement X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:38:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0CB0_01CA9B81.54ED1330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WebEx information: Topic: MARTINI WG Virtual Meeting=20 Date: Tuesday, January 26, 2010=20 Time: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 Meeting Number: 969 608 430=20 Meeting Password: martini=20 -------------------------------------------------------=20 To start the online meeting=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D131322857=20 2. Log in to your account.=20 3. Click "Start Now".=20 4. Follow the instructions that appear on your screen.=20 -------------------------------------------------------=20 Audio conference information=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D131322857&tollFree=3D0=20 Access code:969 608 430=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D131322857&UID=3D48323393= 7&ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3DOq5aMj5r9wtLK2O-DYCma1jCyRz2sv5I/M= MmlsQr8fE=3D=20 To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 http://www.webex.com=20 ----- Original Message -----=20 From: Bernard Aboba=20 To: martini@ietf.org=20 Sent: Tuesday, January 12, 2010 12:41 PM Subject: [martini] MARTINI Virtual Interim II Announcement The MARTINI WG will hold its second Virtual Interim on Tuesday, = January 26, 2010 from 9 AM - 11 AM Pacific Time.=20 =20 Topics will include =20 =B7 Requirements.=20 =B7 Operator perspectives.=20 =B7 Solution proposals. =20 =20 Details on the conference parameters will be available on the MARTIN = mailing list (see = http://www.ietf.org/mail-archive/web/martini/current/maillist.html) =20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0CB0_01CA9B81.54ED1330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WebEx information:
 
----- Original Message -----
From:=20 Bernard Aboba
Sent: Tuesday, January 12, 2010 = 12:41=20 PM
Subject: [martini] MARTINI = Virtual=20 Interim II Announcement

The MARTINI WG will hold its second Virtual = Interim on=20 Tuesday, January 26, 2010 from 9 AM =96 11 AM Pacific Time. =

 

Topics will include

 

=B7        =20 Requirements.

=B7        =20 Operator perspectives.

=B7        =20 Solution proposals.  =

 

Details on the conference parameters will be = available on=20 the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html= )

 

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_0CB0_01CA9B81.54ED1330-- From spencer@wonderhamster.org Fri Jan 22 14:42:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07A13A677C for ; Fri, 22 Jan 2010 14:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, 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 IDnXSvSwmHzw for ; Fri, 22 Jan 2010 14:42:43 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id CC3B83A681F for ; Fri, 22 Jan 2010 14:42:42 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M1WYz-1NoK8H3TQX-00tMVt; Fri, 22 Jan 2010 17:42:36 -0500 Message-ID: <2420F86370FF424887BB7A31CCD0A111@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Fri, 22 Jan 2010 16:42:29 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CC5_01CA9B81.E31EE660" 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+SbLExJCE6DjgvXcP252HZGLTbS9yPKt2jk77 Zdbyjwk42FZNUyQmOS4tfuD7z/7hIKiLdOr7556yb6JFawn0nW jr0AHkwTg9BK0mkfvWvJEOZQtoZDstUshe0TlWqO8k= Subject: Re: [martini] MARTINI Virtual Interim III Announcement X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:42:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0CC5_01CA9B81.E31EE660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WebEx information follows: Topic: MARTINI WG Virtual Meeting=20 Date: Tuesday, February 9, 2010=20 Time: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 Meeting Number: 969 465 025=20 Meeting Password: martini=20 -------------------------------------------------------=20 To start the online meeting=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D131322887=20 2. Log in to your account.=20 3. Click "Start Now".=20 4. Follow the instructions that appear on your screen.=20 -------------------------------------------------------=20 Audio conference information=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D131322887&tollFree=3D0=20 Access code:969 465 025=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D48323393= 7&ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA2=3DWGoxneiNlXpgDU1NsbNn-14QD3ify3AQqg= l-GLxLiIk=3D=20 To check whether you have the appropriate players installed for UCF = (Universal Communications Format) rich media files, go to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 http://www.webex.com=20 ----- Original Message -----=20 From: Bernard Aboba=20 To: martini@ietf.org=20 Sent: Tuesday, January 12, 2010 12:46 PM Subject: [martini] MARTINI Virtual Interim III Announcement The MARTINI WG will hold its third Virtual Interim on Tuesday, = February 9, 2010 from 8 AM - 10 AM Pacific Time.=20 =20 =20 The Agenda and conference parameters will be announced on the MARTIN = mailing list (see = http://www.ietf.org/mail-archive/web/martini/current/maillist.html) =20 =20 -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_0CC5_01CA9B81.E31EE660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
WebEx information follows:
 
Topic: MARTINI WG Virtual Meeting =
Date:=20 Tuesday, February 9, 2010
Time: 9:00 am, Pacific Standard Time (San=20 Francisco, GMT-08:00)
Meeting Number: 969 465 025
Meeting = Password:=20 martini

------------------------------------------------------- =
To=20 start the online meeting=20
-------------------------------------------------------
1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D131322887<= /FONT>
2. Log in to your account.
3. Click = "Start Now".=20
4. Follow the instructions that appear on your screen.=20

------------------------------------------------------- =
Audio=20 conference information=20
-------------------------------------------------------
To = receive a=20 call back, provide your phone number when you join the meeting, or call = the=20 number below and enter the access code.
Call-in toll number = (US/Canada):=20 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serv= iceType=3DMC&ED=3D131322887&tollFree=3D0

Access code:969 465 025=20

-------------------------------------------------------
For=20 assistance
------------------------------------------------------- =
1. Go=20 to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support". =
To add this=20 meeting to your calendar program (for example Microsoft Outlook), click = this=20 link:
https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&= amp;UID=3D483233937&ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA= 2=3DWGoxneiNlXpgDU1NsbNn-14QD3ify3AQqgl-GLxLiIk=3D

To check whether you have the = appropriate players=20 installed for UCF (Universal Communications Format) rich media files, go = to=20 https://workgreen.webex.com/workgreen/systemdiagnosis.php

http://www.webex.com=20
----- Original Message -----
From:=20 Bernard Aboba
Sent: Tuesday, January 12, 2010 = 12:46=20 PM
Subject: [martini] MARTINI = Virtual=20 Interim III Announcement

The MARTINI WG will hold its third Virtual = Interim on=20 Tuesday, February 9, 2010 from 8 AM =96 10 AM Pacific Time. =

 

 

The Agenda and conference parameters will be = announced on=20 the MARTIN mailing list (see http://www.ietf.org/mail-archive/web/martini/current/maillist.html= )

 

 

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_0CC5_01CA9B81.E31EE660-- From adam@nostrum.com Fri Jan 22 15:07:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723203A680F for ; Fri, 22 Jan 2010 15:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 A9QlOUrqXK+Q for ; Fri, 22 Jan 2010 15:07:46 -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 AAC5E3A677C for ; Fri, 22 Jan 2010 15:07:45 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0MN7VYY071756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 17:07:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5A2FB1.3030806@nostrum.com> Date: Fri, 22 Jan 2010 17:07:29 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <4B44B489.6080708@nostrum.com><00e001ca8fb1$d6bffc50$843ff4f0$@us><4B460AFA.9010008@nostrum.com><1FB66BD0D8F54FACAD544F3ED006D887@china.huawei.com><4B46196F.4020006@nostrum.com><4B465EC9.5050709@nostrum.com><4B4664C4.2060403@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10B18D@zcarhxm1.corp.nortel.com><4B4CAF5B.6010303@nostrum.com><09B7DBFE70A9E24BBB21689DAD3A06141C10BAF4@zcarhxm1.corp.nortel.com> <4B4DCEFE.6070300@nostrum.com> <4B4E389E.50308@nostrum.com> <4B4F3D33.1040708@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] draft-roach-martini-up-00 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:07:47 -0000 On 1/14/10 2:25 PM, Elwell, John wrote: > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 14 January 2010 15:50 >> >> Any design for turning names into IP addresses that yields different >> results than the global DNS runs contrary to this "single root" >> approach. It is highly likely that members of the IESG and/or IAB are >> willing to light themselves on fire to prevent any kind of beachhead >> that can be interpreted as sanctioning of such a design. Concerned >> members of the IETF community at large are likely to be sufficiently >> concerned as to file an appeal to attempt block publishing >> the MARTINI >> documents as RFCs. >> > [JRE] I don't see how option 3 leads to this situation. Anyone looking in the DNS for pbx.com will be pointed at the SP. The SP will know it uses MARTINI procedures for pbx.com. The PBX will know it is responsible for pbx.com. > You're still coming up with a parallel system for resolving names into IP addresses, even if you scope those procedures to the SSP. Even worse, you're defining it in such a way that it necessarily returns different results than DNS does. If you want MARTINI's documents to be caught up in appeals after we're done with them, this is probably the best path to ensure that. On the other hand, if you have a goal of getting to RFC as quickly as possible (or at all), we might want to think about alternate approaches. /a From adam@nostrum.com Fri Jan 22 15:22:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C9F3A6940 for ; Fri, 22 Jan 2010 15:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VrEQ5b6Sd29P for ; Fri, 22 Jan 2010 15:22:08 -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 6D1723A6982 for ; Fri, 22 Jan 2010 15:22:08 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0MNM2tR072799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Jan 2010 17:22:02 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5A331A.7080204@nostrum.com> Date: Fri, 22 Jan 2010 17:22:02 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: <4B4F520C.9000208@nostrum.com> <4B5283C4.9080700@nostrum.com> <4B546EA2.8010000@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:22:10 -0000 On 1/18/10 4:25 PM, Bernard Aboba wrote: > Paul said: > > "If this is to be considered valid, then I think some careful specification > will be needed to ensure that it will be used in a correct way." > > [BA] The question in my mind is whether that "careful specification" needs > to occur in MARTINI or not. > > It seems like this issue also occurs in classic "static mode" deployments as > well (where MARTINI mechanisms would presumably not be used). In that > case, why is this problem specific to MARTINI? > Yes, there will be similar and congruent problems that arise in general purpose peering with third-party intermediaries. And I assume that SPEERMINT and/or DRINKS will come up with solutions to those issues. However, if we rely on those solutions in MARTINI while simultaneously punting on working out what those solutions are, then we are effectively adding requirements to SPEERMINT and/or DRINKS to analyze their solutions in the context of dynamic domain registration. Or we can sidestep the issue altogether by using REGISTER like 3261 uses it: to bind AORs to contacts. Assuming both approaches work for the MARTINI problem, which one seems safer? /a From adam@nostrum.com Fri Jan 22 15:30:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A0328C0EF for ; Fri, 22 Jan 2010 15:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, 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 0bmYnIzsw0YM for ; Fri, 22 Jan 2010 15:30: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 1783B28C0D8 for ; Fri, 22 Jan 2010 15:30:17 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0MNU7AU073413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jan 2010 17:30:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5A34FF.6050301@nostrum.com> Date: Fri, 22 Jan 2010 17:30:07 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Brian Lindsay References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C370FBE@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C370FBE@zcarhxm1.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------050809080201000300000409" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:30:24 -0000 This is a multi-part message in MIME format. --------------050809080201000300000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian: Yes, you could. But with that approach, you're needing to define two different mechanisms: * One that informs the "domain routing function" of the SSP where to route the domain pan-am.com, and * Another that informs the "look-up function" of the SSP how to convert "sip:+15005550100@centricvoice.com" to "sip:+15005550100@pan-am.com" While we certainly could go down the path of defining yet more mechanisms, I would suggest that we don't. /a On 1/22/10 1:31 PM, Brian Lindsay wrote: > Hi Adam, > Regarding the case below, you could use a "domain routing" approach > for this as well. > For example, the SSP could perform an intermediate step (e.g. using > a local "Look-Up Function" to borrow from SPEERMINT terminology) that > effectively provides the mapping from the E.164 number to the pbx > domain and does the conversion from sip:+15005550100@centricvoice.com > => sip:+15005550100@pan-am.com. After that the routing mechanism kicks in. > > ------------------------------------------------------------------------ > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* Friday, January 22, 2010 12:16 PM > *To:* Dean Willis > *Cc:* Hadriel Kaplan; martini@ietf.org > *Subject:* Re: [martini] Requirements - rev1 > > [... text deleted ....] > I suspect most people can tell that's wrong by simple inspection. What > I'm willing to bet people are expecting is something more like this: > > > > But that's most certainly not the "domain routing" model Dean is > talking about. In fact, it's pretty much the "contact routing" model > straight up, with an AOR to Contact mapping of > "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" > (and a similar one for +15005550200). > --------------050809080201000300000409 Content-Type: multipart/related; boundary="------------090008030607020607050607" --------------090008030607020607050607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian:

Yes, you could. But with that approach, you're needing to define two different mechanisms:

While we certainly could go down the path of defining yet more mechanisms, I would suggest that we don't.

/a


On 1/22/10 1:31 PM, Brian Lindsay wrote:
Hi Adam,
 
   Regarding the case below, you could use a "domain routing" approach for this as well.
 
   For example, the SSP could perform an intermediate step (e.g. using a local "Look-Up Function" to borrow from SPEERMINT terminology) that effectively provides the mapping from the E.164 number to the pbx domain and does the conversion from sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com. After that the routing mechanism kicks in.
 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Friday, January 22, 2010 12:16 PM
To: Dean Willis
Cc: Hadriel Kaplan; martini@ietf.org
Subject: Re: [martini] Requirements - rev1

[... text deleted ....] 
I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this:



But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" (and a similar one for +15005550200).


--------------090008030607020607050607 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB5wURfr9ejawCywZ yVEUwYjxzKCY9UynnoqZv2c8w3lGTtd8euehYjoT5oQ5B5IJz0BUEMmKBIElbWDDbNf/ve6p nd5xNqeZ3e/b39vK1VWverrfVNV0i6gpA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPK gDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwo A8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKg DCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMJBkDTpK1V5urDCQMAxk9XReN 0c9QwoxIvTTEFK4MheqlJq1EGVAGWhQDqS2qt9pZZaB+GXC2rFA9Vb+UNm1tmb2MDmjTDoEe XRlIWgb0m1jSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEV VIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQ BpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEV VIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVgdozsOo3I1u2mNpX0AQli4uTq71NQJEeUhlQ BpqQARVUTUi+HloZqC4D515qJLNXFIN2N3LlGCPhsC8yCiCO2vQxctZF5UXHex8b+cNh0bhH xhvZ53Ajh58ksv2+IsefaeS3tdH0YHu22SN6PB6723ZGjjjFyK8r4+cPlq1vf856I312EjGm 8Y9d333R+pQBZaB5MqCCqnmOq/aqmTEwfbbIS4+LbFnhyKalvv+DSSJ3j/M7OvsHkTatRd78 QGT9hqjomDFHZFcIEdrET428/q7IOy+IzP7MkblfiqxYJfLUi3568P+adRROIivn+sfkced8 jnI4zuPPBnM2jv+7WSK77CjiOE7jHFCPogwoA8pADRlQQVVDwjS7MtDYDOTmGVmwOCqM0tMd 2X0XR0ZhlmnSp35rKJyOOFhkxyEiL74ebSGF2G47++Gb7xY5DHk6d/JFSWamI//8h8ghw6P5 rW8Gym09QKRjh6iA6dbVkT69RHr39HOtw6zReX81wtmyw04ysmhJVMi99IaRnQ/w08bcHo1/ 7R0jux1kZKvBRs7EbFp+gZ92x1gDoWZk1AVGHsYsWlGRkatuNLLDfkZOOc/IJ1Oj/bBtVFcZ UAaUgURiQAVVIo2GtkUZiMPAzO9FunQSiJmouGG2zAyR9FZ+AQqgYZiJOvd0kfGYgbI2kzNU EUHVq4fIvzCjRaHC2arCQiMHHeBgBqt8vSxLIcaZLe5bIlauNpgNM7Jxk8ifT/BrPxbH6t9X 5KMJvpC74G9+/CtvGrn132jHA5j9elDkoSdFvptl5IuvjdwxVuSZhxCeLPLjApHHnvHLfDBR 5L5HRXbeAcuQR4lcfLXI4mUi//2PSLetRB58Iioo/RL6XxlQBpQBZUAZUAaaBQMZPV1s6Wl4 G/uwa4457ffHuux611xxgx+/8wGu+fRL12zOdU3nQa75erprlq9wTbv+riku9vNs2uyacY+5 Zu/DXJPZyzW9d3DN86/+vl726ISzXMP+BcEys77387/7kWtOPjdadsYc1/TdyTXhsGv67Ii2 TIumPfSka5Ysc81Rf3bNxE+j8dfd6poL/uaakhLXtB/gmg8n+Wk//+rXkZfvh39a6LeDdTS0 sb/N4uTUTigDykCjM6AzVI1OuR5QGagZA8F9ULZkaamRDyeJnHGKSF6+kYVL/NmdrLaOnHSs P0vFclwCTEvzZ6DaZTlyyWhHpn3oyPyvRfb7A2erbI3lXc54vYu9VesW+vjxK8wUdRV5/lU/ 3z/vE/l0msjAXY2HP57mzyR9+Q1mzdJF9kfd1i48x5ENmNla+ovIQfvbWJHNuSKcNZuPY3Tt jOXIg/x2Poi9YqdjObNNaz/cCrNwHdqLDOj3+5m0aG3qUwaUAWWgaRlQQdW0/OvRlYEqGeDy G5fzgvbMyyLtshC/oyNcEuTSW/t2vuDgst+EtyB4sOncLvfxl36fTI1OvvTF8uEZJ/vLhsF6 6efy3uo1Invu6osaCpv+fR3Zdy+R1FQ/N4/5Ptow/38+fsCxpuCYCxeL9OgW3TzOXxB+Ns3I LOTv1iUaX1LiC8KzTxXxliUD/ZuFje8Ub9beeE+X+ywX6ioDykDiMqCCKnHHRlumDGDPkpEl y6KCirNRDz1p5HbsLXryfp8gzibZX/IxZo9hDmZz8Gu857CROyJUKLUmfebn539udH/0GcwE /SkaZ32sb9BAEc52BW31byLbIB7LbhBvmHH6mbNRjqxeK7LXoeJtnGf8GoQ3bDTCWbQLrxLZ lCvSGr9AXInyjKc9+bzICMxW9e7pC0L+gs9a2zYi87C/ysXq24pV3KSuG9ItN+oqA8pA4jIQ +b6ZuA3UlikDLZkBzt7QBu/J/8ab/TlwH5G3IUiGDvYFDwXQsIAgYU7OUl05JjpDdev1gl/V 4bEK7+MXdpgpKiwSGXmgyI1/Z+7yxqXC2PqYY9lywa/y/FmmG67kr/RE/v2AkZz1Inf8w58t 22agkbEPY6lxP38J8KhDRI45zMHynpH/POQ/+4p5uIw3fpx/XM5eXf3XaBv++n8ix54hMu0b EYqr3lgWtDNt0VzqUwaUAWUgsRgo/xU0sdqmrVEGEpoBbmDm85mSxfhkdD5+oVPH3/9isDZ9 WJuDpUHMOg0e5M9UBev4ZYXxhFAoFOWHM1Y8PvdD9egWjQ+Ws37OzK1d58+UNeazp/gA08KV gUbbBqmrDCgDykAVDFR+VauisCYrAy2ZgWQTVC15rKrbdxVU1WVK8ykDykAsA6HYCA0rA8qA MqAMKAPKgDKgDNSMARVUNeNLcysDyoAyoAwoA8qAMvA7BlRQ/Y4SjVAGlAFlQBlQBpQBZaBm DKigqhlfmlsZSEgGFi428v4n/iMJYhs4d77/8M3Y+LqG+a6+ad/GP2Zd69byyoAyoAwkGwMq qJJtxLS9ykAcBp59RfCuvDgJiOrbW2Ti6/HT6hL7wqN4+OewutSgZZUBZUAZaD4MqKBqPmOp PUkyBl56wwhneQbtbmTM7dGZni+/MTLyeD/+kmuMhMN+2s13GzwQ08jJ5/ozTufjWVB8yOYd Y4089qzIq2+JfP4/P/z4s0ZGXcCHYhq5H8KHTx+nLVhk5IhT8DyroUZOO9/Isl+MjHvMyD/u iB7/5+VGDv2TET5mYfFSI388Hc+uGmzw8E4js3/w8/FFx3wwaGqq4+W7coyRvjsZ2f8oI29/ 6Odh2+59xMiw4T6efzV6DL81/n8eJ155vrz5mpv9vvIVN+wLjfWOONbIC6/5x+Mxv5lhhHxs vZuRsy823kNB/dr1vzKgDCgDyoAyoAwkNAN8bEJt7eU3XDN0H9dMn+2az//nmo4DXfPtTNcs WOSabfdwzStvuoYvBd7tINc8+IR/nN0Pds2eh7jmy29c8+wr/guD+QLkX1e6ptPW/guJt2xx zX5HumaH/Vxz9zjXrPrNNSw39QvXrF7jmn47u+aZl1yzaIlrDjnBNXxB8SPjXTPy+Ghf+MLi 2+7xX6rMetiWdTmuuTrbNfsf5ee7817XXHqt7z/lPNeMvsw1S392za3/Rvv39OP/9YBrjj7V 79d7H/svQGZbY62i8nzxM4/Bdn88xTVZ/VyzbLnPEbm/6O/+S6D3OtTv/9Mv+i+IZhrz1cZY NqFPOm2cMqAMKAPKgDLQ3BioraAKh13TZ0dfANmb/kNPumbJMtece6lrXoLYsjbmdtdcfj0e IAqh1KaPa+b95KexDh4/Z70vZLpt58eXlPjC5cNJfpjl2vZ1zYaNrrnkGtf89bpo3Z9Oc83b H7pm4qeuGbK3H09RNGh31+Tlu2b8C6658Kpofgq+rQb7YYqgJ5/3hVr/XVzD9tAovCi2cvN8 wciwNR6D4jFoFHrxylNEUVgWFUXzU6h9MtU1FKPDhrvGdf20k86J9qu42DWte7tmbeC4weNV 5VdB1dw+pdofZUAZUAaUgYRnoLaCikJm692igsDe5CmoKAYoMAYM89FlG9f88z5/lme7P0TF xXzMXlGU0d54zzWH/sn3fz/PF0S2TooglqP46LuTa6Z9E63D5ln2i2s6YIaMdv6Vrnn0aT8/ BdCMOdH8kz9zzS4H+mGKHaZdBrF31Y3RPLbO/zzkmnb9o/1gfygIFy4un7ei8jfc5hrCGtvf c3vXzJ3vz6pRaFrjTN//vvPDs773Z+FsWk1dFVQJ/7HTBioDCcuAvssvYYdGG9ZcGViI16/0 6Oa/E499/G2tkZ8WimzcLDKwv8j0SdGeb87Dq1rwwuGnXhTZfZdoPN+3Z18ozHfh2Xfv8d1/ wRcl27RNqHsNXuXSq2e0Du51OvwgvoZG8CJjke9mGfl2hsiDd+GFxsjPlx933yqa/9V3RM4/ S2T9BiOr1uC9fIP9FyIfOjyaZ/psIx3xahke97LzRcb8zU8Lo/7CQr72pvzLGfgqmnjlZ6D8 kSOj9U75HO8u3NZ/f+HM7438Be2gbdps5JdfRXYa6od5XMuLH6P/lQFlQBloHAZ0U3rj8KxH UQbKGGgPgbRmrciGjQZCxsiFV0EY5Ipk4UXAfH9dwRb/3XhvfyhyyAkUXiIzIRSsaGJFFA5W OM2ZJzJkG7965gsKCq/cTiKt0gG8kJjCjfbMS0beeNc/Dt+3N7CfyOV4gfJNV/sbzdPSRIh5 P/n5lywzMhmi5uw/+8ceCjGVnu5I+yzUucjfKP7rSiPnXirSsQNeatwWguwX1uWLtUuvEW9z PGv7erqRRUv8rUoVlm8tMh9txQyTlJQYuQcvVv7bxX5b2Pdh6BNtNjbb812CmZm+UKMQC/Lk 59L/yoAyoAwoA8qAMpCwDNR2yY/7i/Y53DW9sIS16wjX/OMOf7mK+5AOO8nfp7Tj/v5G8cVL /TTmn/J5dJmLG8q51EfjMh2X83751TUj/uiaDyZG87Ec9x3Rbr7bX1LcY6RrjjzF32juJeDf iWe75sBjouUYf/2trsns5ZqDjnXN9vu6xu7L+veDrvkLjknjEiKXJZnOzeEfTfbjf/jRNb13 8DfHs23cYM79XbTBe7nmxdcrL89lUW60514pLumxLTQuT3Lpz9q9j2BD/OXR8AFHu+atD6Jh m6+6ri75JezHTRumDCQ8A+Xn3xO+udpAZSBxGODNd8uK2n+EfllhpHcPEc4QWcONH7M3Iikp XP6Lxtv0ityNm4x0aF91/pz1xpt5apdVdV4ea8UqI3n5IoMGsE3xyxQVGcnZINKze/l0PvZg IfrSs7tI507l04L9qKh8Xr7xlh0HYPasbZuKywfrqqtfX45cVwa1vDLQchlonKtUy+VXe96M GairoGrG1CRt11RQJe3QacOVgSZnQPdQNfkQaAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFl QBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaSnQEVVMk+gtp+ZUAZUAaUAWVAGWhyBlRQNfkQ aAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaS nQG8GEJNGVAGlIHkYYAP/FyxSmQlwFf28MGj+UBeAZAnZtNmpxjvQAyzR5mtJJSRISmZGSYV r94J8fU7fA3PVl1F+vUW6QsE36uYPCxoSxOcgXjPeIwXl+DdaFbN8993Vb5L8eLK56hBSAVV DcjSrMqAMtDwDKzN8Z+wvggvTl60TErxkuYteAFyeOVqCa3NkVZ4kbOTmSk5rdJkBR4sv8l1 ZXO41GwqKpYNeAHzBscxecBmMU6KcaSVuNKKbmoo1Co13W2TliIZGa1CA1zXDCwslh7FRdJ6 qy5mS5/eDl7hLHgToZoyUGMGKJasYIr128psug2r27gMBMWT9dON569Vy1RQ1Yo2LaQMKAN1 YYAvhV60VOSHH/lyZcf94UdT8OMCJ7xsucmEAApntpZfjDjzNm5yZ0qpWWlCZoVx3RXFhQUr ZGPHjXm1OHhxhWWWZ65wt+q38rdQP1cMXk+tpgxUm4GgeOIWGoata/2sLJiPYbXGZyAonlwc 3oatny7HycbXuIUsrKYMKAO1YEBfPVM90tasMzJnri+eZsyR/JmzJbx0ubRpnSE5aekyJzfX mV5YXDrfuGZBeMuWBZLbLqd6NWsuZaBJGbAiiS5FlAXexOn56do0mxdRXhxdtcZhgAKJZoWS FVCckabfuvTbNJsXUdU3naGqPleaUxlQBqpgYBnmlWb9IDJjjhP+6luTP2eepJUUS2lmhizE S5C/yd9ippe67pyS0Lof8hf2xK4nNWUgaRmwIolCiuLJYiP8TFNLfAYonLjMT1FF0CiqaFaI +aFq/FdBVQ2SNIsyoAyUZwD7j2TBYvHE0/RZTvFX30nB3PkmMxSSfGz8/j53s/tZcamZXlxY PEPWt16+oXxxDSkDyc6AFUxWTPFeSqQBjsHmPrXEZ8CBoZX4qYqUAHZM2XCKK4ZrNJAqqEid mjKgDFTIQHGxkXk/+eLpu1lS+L/vpAhiqnVGK8lJTZVZGza5nxnjTi+SLTNkZTvdg1Qhk5rQ jBjgzTa4xMd7KX4/6t2cm1E3W0RXMtBLK6YooCzs8l+1SVBBVW2qNKMy8HsGcvOMZLW1n8Xf pydbTM56f7/TbOx5+naWkzd9lnF/XSmt27aRFejldxs2mS9KxZ0RLtk4M/fnrnhogZoy0GIZ sKKKS32cmeJMB2/OasnFgB0zCim7j8ou+9WoJyqoakSXZlYGogx062qe7LWDc/rO25vC449y so4YaUJDtk0OccVnOf24QGQ+MG+BUzJjjimYMVvSC4sk1C5L5hcVOl/l55V+W5rizipZ+fPc fNmmKNpz9SkDLZ6BWDFFQcUZqswWz0zyEcAxo4DiMl9QUNVYVCXH1T/5Bkhb3FIY6LmydavS rQ7Kap9ynHHljxkZpvUxhzkhiKvMwYNEtu6PjRWpTfMxKykxguc3ybLlIj8DeERB8awfnIKf Fpk0PBAzPauN87Mj5ocNm813Jmy+d0Kh+11TclTx6laYn1JTBpSBShiws1IUUZzhaB1BW7hf 6x4qsJAE5m+hkr3QVD6JhT+SIQoBPmWF+6rsRnV4q7amudJX3S7NoQwkJQPpPYqGpDipR3Xo 6BwVLpHtCgqkS6+eUrDjEEd22VHaDh1sQttuLVgmxE9L2otgNkgiH+pq95cbwnOwyztnvcg6 Ag8ZoH/1GnEx61SwcImEf13ppG7caDLbtJb1eDTBL3ju008bN8pMbA/40TEl8wp/y1iGI0c3 XHbN656R1npe4Uqnc7n4ardKMyoDLYYB3jetoOIyH2c4KKjwafaAPYXRjxbi1BKUgci19wA0 j9sXCAqqLQBn5K2gqvZgqqACa2rKQMMxsLBVWtd+Q5y00NBWqc6O2G+1J57sPSBcKll4snfb khJp1TpTirBHqaR9O3EhsNziEnHCeHFKaakjJWHj0IUgcqCjZPNmSS/YIun4JV1Beppswqbw 9fgQr8GTwlfn54eWhEtKl0I0AeFlhavfwbzUydX6hpXePXwyZqhOL1oZOrbhuNCalYFmwQDv m9wuw2U+OzvVBn4KKv4E/xMVVGAhCSwiqA5BU/moCwqqfMDOUlFQ8RVW1RZUuocKbKkpAw3H wDZFJWtlFuqfxTlkfmLLW3aosN0VHfJzW3VctTbUEe9KaRuGfsJf2AmZMH5HFHZKI27YhIvS ijfIyv+s3yLZNV7fL3/c8iFHnP3FNZ+Xj9WQMqAMVMIAhVXwl34UWIRacjFgx42zjnY8azXZ pIIquQZeW9vsGIAw2py9vmizYNHOn2Nuii46xn2jsDAfS4JqyoAyUEMGeBPmzZjQe2oNyUuA 7BwzO34cy1qbDn6tqdOCykDzYaDwt7TJzac32hNloFEY4CyGhZ3Z4I1ZLbkY4JjZ8bPjWasZ qjqpseTiTFurDCgDyoAyoAzUKwPBG7C9KdfrAbSyBmfAjltwLGt1UBVUtaJNCykDzYeBVt3C R7fqUXJY8+mR9kQZaFAGgjfeWL/eUxuU+gapnGMWO47BcLUPqoNfbao0ozLQPBlwUkLX4wEK 3DOvpgwoA8qAMlBLBnQPVS2J02LKQPNgYGkGfhO8S9Hq1f9rHv3RXigDyoAy0DQMqKBqGt71 qMpAQjCQ0b33H9CQ2SJ9+DA7NWVAGVAGlIFaMqBLfrUkTospA82BAVdC+xvR5081h7HUPigD ykDTMqAzVE3Lvx5dGWhSBooL8h6UzWv4dGA1ZUAZUAaUgTowoIKqDuRpUWUg6RnY3N57oGjS 90M7oAwoA8pAEzOgS35NPAB6eGVAGVAGlAFlQBlIfgZUUCX/GGoPlIFaMZDeM3xqq+6lf6tV YS2kDCgDyoAyUI4BFVTl6NCAMtByGHBM6BRjzK8tp8faU2VAGVAGGo4BFVQNx63WrAwkNAOO IwcUlxZ9ltCN1MYpA8qAMpAkDKigSpKB0mYqA/XJQHr3oqHGyAZZ12ZVfdardSkDyoAy0FIZ UEHVUkde+92yGXBSholj3mjZJGjvlYHmycCoUaMkPT1d2rZtK23atJFevXrJ5ZdfLps2barX Dt9///3iYKr7888/r9d6k7UyFVTJOnLabmWgDgwUr0p9vmhlylV1qEKLKgPKQAIzcNVVV0le Xp7k5+fL3Llz5f3335fx48fXa4ufe+452XPPPeXFF1+s13qTtTIVVMk6ctpuZUAZUAaUAWWg Ggx06NBBTj31VJkyZYqXe+XKlV6YM1eHHnqoTJo0yYufM2eOnHPOOXLXXXfJwIEDZbfddpPZ s/Fmqjj2008/yYoVK2Ts2LEyYcIECYfDZbmOOOIIeeaZZ2SvvfbyBNfUqVPloosukt69e8sJ J5wgBQUFZXmbk0cFVXMaTe2LMqAMKAPKgDIQwwBF0csvvywUOrQHHnhAevToITNmzJAzzzxT LrnkEsEvfr3ZLM46UXB9+OGH0q9fPxkzZkxMbX7w+eefl5NPPln23ntvyczMlIkTJ5bl+/77 7+XRRx+Ve++9V4YNGyYjR4708rz77rtCIca2qCkDyoAykPQMpPUIn5HR030l6TuiHVAGmoYB TkSkA1lAN2BrYBgwAvgTAG3StHb66acbtsMiFAqZQw45xGzcuNFr2BdffGFyc3ON67pm5syZ Xr7NmzebadOmmc6dOxvMNnn5vvzyS7PNNtvE7cyAAQPM119/7aVddtllBsKsLB9mvgwEmRfG /iqD/Vze8RiBvVzm2muvLcvblJ4IPxwzjh3HkGPJMeXYcoxrNOmkr54BY2rKQEtiICSOvhC5 JQ249rVFMsBN6HZ2iRvTMzIyynjg8txxxx0nEFOyww47lMXT061bN0lJSfHiuKl9y5Yt5dIZ gNCSpUuXygUXXOBtSs/JyZENGzZIYWFh2XG4vEfj5vi+fft6G+QZTk1NlZKSEnqbnamganZD qh1SBqpiwNnfLQk/VFUuTVcGlIHkZYDLcJht+l0HSktL5bTTTpM777xTPv74YykuLvaW42xG zGZZb4UulwXPPvtsGT16dFkezIp5G9+5R4pWnXrKCjcTjwqqZjKQ2g1loFoMdM/tKo70KFl7 x5xq5ddMyoAy0KwY4EwSZ5SOPvpoT/Q8++yzNeofBdgrr7zi7bHaY489ysoef/zx3q/9rKAq S2hBnqqlaAsiQ7uqDDR3BtKk1QAj5k6RbLe591X7pwwoA79noEuXLt7sEjeLE7NmzRIKIz5m oTr2wQcfSPv27b0ywfwUVO+9955gb1YwukX5nRbVW+2sMqAMKAPKgDJQNwY4EcHVnVZAa6At 0A7oAHCNbQI2WsNJbFu1apX30M927doJlwGxYT3uEmFi96JureNDSWEnATnARmAzkAfwuQ5F AJ8FUe0vn7rkB7bUlAFlQBlQBpSBlsQAH5tgjZvQ4+23sunqVo8BXfKrHk+aSxloBgxkh9K6 F++JX1PrzHTjjib3q50WOeRUuD8DnNmwxpkOTml0AW4HPgVi7QVEPBeJtPVdjXBxBKVwCRu+ Cf4/At5P4mPc3/9sCxnUlAFloG4MqKCqG39aWhlIGgZa9bjhkBQn9W7BS/ySptHNs6FcHrqh gq7xHR77AVsF0vk8nKMAiqqgYSy9Z+Uw/UFgfCB8M/y0uQAFdBCZTFBTBpSB+mVABVX98qm1 KQMJy4Ajof0xYfF5wjaw5TSMQuhCYJs4Xf4BcfOA4wJpB8PPB/d8EohTrzKgDCQYAyqoEmxA tDnKQMMx4BxgHPezhqtfa64mA8uR79/AuArycybqxEDaCfC/CtTmaYjtUe7PMdgNYbUWzsCo UaO8h27y4Z188Cff68eHgW7atMlj5g9/+IP3ME7ureLG9Z49e3q/BOQGdj7sc/DgwYInpJdj 8bDDDvPeEVgusgUFVFC1oMHWrrZkBuamY+fU7kWlOdNaMgsJ1Pd70JZBwPFx2vQS4kYAHYEU 4FiAS4G1MdZxfgz2rU1FWqb5McBHJeTl5Xnv8Js7d673YM7x47ly7NsjjzziPbMKr6URPi5h 3Lhx3jv7+NBQvvz44YcfFr74mMZ39/Edfg8+yNXnlmkqqFrmuGuvWxoDXfp3MeKeJ791z29p XU/Q/vIn2fx6PxYIblBnc5cC04FjAAqywJgAACAASURBVO6nYt7aziwuQ9mDYnA/wmrKQDkG OnTo4M0uTZkypVy8DQwZMkT4DKvIowZkr732kr///e9yzjnnyA8//ODNXj3++OPSqVMnW6TF ufrYhBY35NrhFsnAujYr8fOv2s5ytEjKGqHT7+EY3Et1fZxjcay47Edx9TJgADVloMEYmD17 trz88svesp89CF5sLHzvX1FRkTczxffzjRjByVPfbrrpJu9hnhRXfJ3NkUceaZNapKszVC1y 2LXTyoAykCAMXI52XBCnLa8gjpvRTwLqIoS5ZMgpg1jwV39qLZwBvs+PM07Errvu6r3E+NRT Ty1jZc6cOfLRRx/J5MmTvZch8+GfixcvLkvni49HjhwpBQUFctRR/CFqyzYVVC17/LX3LYSB Vt1LL8JkR/R18y2k30nQzUVoY7wluNWI/x/ApzZz+a+2th0K5sRBVm0r1HLNhwFuQl+3bp2H /Px872XJfK2MtYsvvth7Px9nrr777jtvBuqBBx6wyd6eqYceekj+7//+T6644gpPWJUltkCP CqoWOOja5ZbFQFrP4mH4CnqJyIDCltXzhOntTmgJf7lHGw7YB3QyTLsB4IzROgYCNhL+wYGw 9Qbrs3F/hWe0DUTct+Gy3njYHJNXgy2QAW4u56/4iIyMqr9vDR06VLg0SOOv/c477zy56KKL vM3pFGI33nhjC2Qx2mUVVFEu1KcMNEsGQiblAGzB+axZdk47pQwoAw3GAPdOcTmPs1dvvPGG jB07tmyf1L333itr1qyRm2++WfjqGs5U3X///TJjxowGa0+iV6yCKjFGiN9Cuek0Dega8T8M N2ijEJgciVgAFzMO5YxfL3KBPwLB+r5G2L6Ogsfgs2xseAf4+W2Z8bF4BnFqzYIBZ3+jD/Rs FiOpnVAGGpOB0aNHe8+o4rOq+MypQw45RK688kpvHxVno7j8x2dY0fbZZx8544wzvOU/zl61 RNONiYkx6hRA84F0gG8sXwNw38NhgN0/QUF1LnAQcDOAp157fjieHYP/TwPdgQGArS/4MMBV iD8L+BiwRkG1EGCdas2QgYwe7prCosLdZH1rPlBSTRlQBurGACciUoFWQGugLdAO4LW7MzDB GH4/VUt0BiKPgOAPP3i/3QhwKZz7FgsAPq4kDLhAtYwnhlpiMnALmvUg4MRp3ouIwzKON5tl k0+A53WAs081Nf3015SxpMm/NKPUCR+uYippBqyhGsova0OAvoBe9xuKZa23RTNAla2WmAw8 hmZxNukc4MmYJnL26XuAT1B+HOA4cobqFKA2tiMK/Tmm4CSE18bEaTDpGBhQWLJSmnpTw6+g 7QiA52x92n9R2UOAv0vWnzF4IuYATJ8GcDbhCuBAYDFwJ7ACoG0LXAzw3XpTgHsAfitlmYrq 4xea84Gg8fNaCvwd2DmQMB1+PsCTxs/saQDrHw8EZ4sR9NK47H8fAxGrqH1Mrqq+nZCHX874 jXsJ0BvYG3gJuAPgt3A1ZUAZqAcGVFDVA4kNVAUvzNwn9SbwRpxjcJaKs1IUVLy4c2aKN4Pa 2G4oxKnqoP2IgAqqICPqry0D+6Dg6toWjlOOXx6I/wNeCKQPhJ/7AscE4n6O+P8Fd3fgWoDn Oz8r2wMUTW8DE4EbAC59U9BcDVRW33Ckc4ngQ8AaRRKNwuo2gEsHNNv3A+F/BOBxKOqeA/gl aBowFDgeoOij2LHG5aSK2ldZfSzP51jhcRkeT/lwdwZmAh0Blr0XuBBQUwaUAWWg2TAwGD0x QHBTenqkd0/DfRAYBUyOxNHpCxQC7QE+GIQXR2vB+mwc3VXAocEI+HlRvzEmToPNhAE8f2qc dC7o1UjdOQDH+QCgEH8F6ADQ3gS2BvYDeJ5yBoj7uXg+9wesvQ/PdjYQccfB5TketOsRGAts BigMrB0ND2d2Yy0FEfzC0SeQsAb+Q4ATgf8F4llfDsBlsYrqY/ZngNjPEuMdgJ+zePYyIv8W SODn1rb3SPjZp+8AxlurrH2V1ccvy98AHIPOAOu9BLgT4JcltnMqkAHQeA24COAYrAQ4TqyD 1hN4EVgBfAxQqNE4+zUeuAZYAkwHdgYqspuRMB+YBXAMrfGcORP4GmCbhwMPAb8C3MbQGog1 juldwBqAZc4GaBy32wD2ge2luGZfabU5jl+y/H8eIx3IAroBWwPDgBHAnwBsoVJLBgY4VpEx 49hxDDmWHFOOLceYY11tq1HmateqGeuTgWtQ2anArjGV/oLwt8AfgeMAXvDUlIEoAxBSTsg5 VXJa88bSGDYOB/k3sCfAa8vFAG13gDfFTsClwEaA4moBwJufNX5BcG0g4vIGlRkTdwfCnMlZ HxM/CGFeED8HeJO1x+8Lfx6wHLC2CJ5tAZbhDd4aZ47Yzi5ARfUxL49DEcCyHwJ7ALQeQBh4 FfgeeATgjBCNZWKPtY2X4gsZ9mlKJGydytpXWX3s208Auf4z8DbwAPArQOHCGwn5Y19pzE9e KVIOAQ4FjgRoFGIUibsCzwCshyKlDTAKoOA6HPgZuA2IZ7xZHQGcAJwCXARY8bUj/OcDlwMz gYnAFuBoYDDA/LHGseUx9wVuBCjAyBXrPQzYCzgIOB04C6DV5jh+Sf2vDFSDgdRq5NEsTcvA ahyeF6l/Al/ENIUi6iaA+yB4kayttUZBe2G1dZTAk2sD6iYfA+mt0g/Aj40+a6SWp+E4WwG8 AfKY5wLtgFiz5zNv6H8DlgIhgEKKN9u62AAUTgd4g90OuBXgZ4MiaRMQtF8RoCDoD2wGrFF8 sm1Mq6i+x5E2EPgK+C9AwTIJGAr0B9oCbwIbgDHASwBv8v2BYDuWI8y8lVl/JFbUPqZVVN8g pC0DaCcB5JpGsfsB4AD8Fr4SsPY0PJ9GArzeHAW8DbwHzAbygR8AcmvbzeNfCZQC/waeAmhD gAzP55dhvtOARUAngDzvBrBeGseKfKYAZwO8ruUBHwPbArHG8+tuYGEEF8Dl2I8G7gPILe1B 4FTgKYBW5XGy2+CX0iGZBIJ4Hrj4Z8AWz0+3LA7PIfESwSPcEDI5Oa7M+W+BxxWPo9YCGUht gX1Oxi6PQ6N5ocDnuZxNQIgXD36rrItdg8JE0D5C4PBghPqTiwG8oWt/3As+b6RWU4CfD/wH 4Pn4KnALEGu8ofJeROMNmjcq3qDnAdbOgccKgC7wTwXCwPvA1UBFdhkS+Blh/ZMBih7exK8H OgNB45cICq1uQDAtE2H2hTfkiup7HGk9AduPL+Cn+Dga4IwUBYNNWwv/1wCPUQCwP9bawEM+ KjOWqah9ldX3K8odF6mYwo7H7Q3sBzwAXAd8CgSN4sTaUngs17xPUCAOA34AgvYbAhRTtDyA /NFeASgwaX2ALQCF7gnARsCKLXg9Y3tpxcAvAOuihYE0z1f+X38EfwxEPRPxM558W1sCT1cb gFvlcbLzZXV2FtroyD4sF3vR9eIQyfgQA7DNrrzzdIE8D28HL0L/tUgG+EFRa3oGfkIT7OeW F2Drty3jBd5enGwcXeaNd7EJ1hfM3yMYiPhHwSXUmhsDxtnflfCTjdQtzg5MA7YBdgIoYm4H TgOCxlkRa1vBQ0Gz2kZE3E/gUuzQ3gB4888B1gCV2XAkcsaDAoJGUdAP4A2ax6XQ4TIXbQAw F+gF7AJY6w/PAoA38uFAvPraI343gKKNRvG0DGAbKQ55n50H0JYBFD4UFGwH22OtPzw2n42L dX9GREXtq6w+Cp8dAc4S3gZwLBYB5wGctfkf8DcgaOTIGstSLKUALwAcg0MBjjP7Ys21nhiX 5YM2DoGOAM+PzcA7QNAqqieYJ+ifj0DwenYIwozjmPYGLK+D4efMl7XqHudpFPAElS1Ykbux FA8Qz5dnka5iqiKSWkg8P/hqyoAy0AwZKFoV2rFkVfp3jdQ13rhnAhQbc4CXAQqYWNseEQTt DICzDFbknAp/Z4CzCJ9FUAyXN0SGecOszE5C4n2RDF3g8ovCa8BK4FvgXIB2MsB0Cgze2Hnj 3BZoDVwLTANoFdVHQcEbKGekaHsAuwEfAN2BSQB5oBi5BPgIoKh6Ezgb4HWXwoLts8eCN65V 1r7K6iNvdwNPAUuAwwG2ZSqwFzADoJgM2gkI8Et2W+BE4AuAIqgz8C5AMcIxq41RaFIoU0xR zO4LOEBNbG9k3j1SgLycBrQCKKwogDYCbCfbmAGwfo4Rj1szy8UMm8FsGZb2KixopCgnLBdC TD1YYR5NaFEM8MOjpgwoA8pAXRlYhwreA1YCXHKhYLkciLVliHgFoNjgTe90wNoL8PCmmWMj aujeg/wUUJxVGgR8CvDGSzsbmAxcBFDoUTCEgaXA1cB0IA9YDQwHaBXVR7FyHXA/cDswBGAd LD8VmAhQXLKPFE/HATTmPxhYDnQAHgaYtzKrrH1V1TcBFa8F3gQoqhYAvYH+wIcA2xE0tp95 MoF5wF0AheBTAPtD4TsNoDj9N/AUUF17ABkfAUYDpcAzwA0Ax6u6djEybgK+A8YDFLDsF8fx TiAXeBb4GFgEsD90PwKqbTe2wab8kHfupkGSUZTFs/XrXDl1XIF3rrWNl0HjWh4DFZ0sLY8J 7bEyoAzUBwP9UQlvyD/GqeyPiKPIGgn0BygWDFDf1hcVFgJrYipOQXgbgDdZ3oSDloVAV4A3 6FirqD470/QLCmyJKcT6tgLYRzcmjfXx5r8hJr6yYFXtq6o+isiBAPtnZwSDx3sOgS8BCh3O rlEYB42zQPnAZoA8UhDmADUxnhfkmHzRyE/sGHkJNfjXB3nZVoo0a3ac2dbYftg85dzzsXWi V5Y3Y/g3SKjtvUTMQMHPGTDfOFsFgYUTdhE2oB87Ls8TpK2RSEHVDiAnnQF99QxISAar71fP pCZDp7WNdWKAFxx+4Hlh501GrQUw0KqH+6brhu8s+S3960bu7rJqHI8Cgzf2hjJ7w46tnzfd +bGRkTAFCRHPKqqP/fgpXgHE1aa+CqryoutaH0VUPCEVe0yKJiLWVgUiyGNNxRSLU3QGuayr mGKdy/kvxiob53JZs7nM205GY2bhKiTwWkmJvwL/H8w18gQunN87DoRfREzB/RIDcRzEFMVa VGyxnFqLZ6AhBdVYsMsp13/UM8unoT5+y7F7JVj934Gd6YnYdLg8Pu1YgGV48RsPcDqYxg/D FcCBwGLgToAfJFpF9bHME16O6L+H4J0GHADgi045OwuhUmBbgNPV/HY8BbgHYHus9YLnfuBE GwG3svZVVR+/Ld0OsF5ewEqAg4FlAPvG/jaEHYlKlwHz4lTeEOfD3jgOx5T7M9QsAz1X8lvz oSW//XyKjUoQl+Lj6QRpizajPAOvIxgUO+VTm1kom18ys+QSCKkr0TXeT/gchB8gnv5pcuVl pHszmNlt8Xw/B7/29GemXszJlXPG+dfThrx3sjlqSchAQ54Ut4IPU4+cDEVdxwMUQS/F1Evh chtAAUfjPgjagQDX7blWTxHxHMCbDAXQv4DdgWuB3YApAKd6KT4qqm8g0nYAxgDWfo54hsPd CHwYCdOhaOLs0NvARIDtuBngB/hqIAsYBZwBDAKCVlH7KLQqqo/leby3gOuBr4BdgVUAx6MP 8ARwHMC21reNRoXvAvEEVX2fD2z7DGAkPS3dWnUL/xEnW5eS31KfzCjtujf2gICbbYoSjBcK KkIt8RigoGr2lo0ZKSdLLjWYkYJ46uJ12MjXCN+Rnevtt4M3YC6WQENyGSJvz97sTQ4wPRTI oV5loF4Z4En5X4A3bc4M7QXQ/grwBkubClA4zAIWAMGZGN74/w8IGgXGIcEI+Dn7wVmO74AH AGv4klHjVz2koEwxQIFhbQ08PGZl9R2N9MdsgRj3GYQPjYljkH39XyD+QPhzAH4oewLs04sA j2+tsvZVVh/L3wNQeNIeBjiDdjfwPrA/cBlwKmDtKHi4DLIcuB/gPgfaTsCnAOOfAtoBtCuB i4AJwArgZSADuBTYACwDjgUuieB5uBSgwfOhF8IfAeuB14GdgbMAil9rHeD5BmgP9AAo1DYB PIeGA7QdgBc8n7+v4y74ySPLnQ1YOx8eijyC7Yhn5DxeeY7TbcBKgP1lX3iO0D4AzgS+BnjM 4QD5/hVgv1oDjWKtuoePyujpmrTuxXtm9CzNzuhReicPzHCjNEAPogwkMAO4OLW6uZ1cdnOW rIZrCDxr6nNsQD+4qmYjH6/7QeM1IR3IAroBWwPDgBHAn4BkeOuKthEMcKwiY8ax4xhyLDmm HFuOMce62lajzBXUegHiC4CdgCeBRwHaAKCf5/N/uXM2/DzZOEvzOMDG0ihsSjxf9N8e8G4X DXq+9/H/CmBKTDxvtmHgVeB7gDfljgCN5PAGbG0xPNsAfYE8YDlgbRE82wKV1TcI6azzc4A3 0IsBa4znzZXH4ywV+0Bjmdg2dEJcF2AlwD79BwhaZe2rrD7WcSDwFtAd2Bu4CPg3sA/wFbAG 2AqgcXwoiP4OHAqwzRQc7YBJAOuhCOMYPQPQ+gB3AC8BpwK8YZ8EUDiRE/I/GaBougVYB/AY wfOB4fkAhdRC4AmAouRsoA1Ao9DjebUJYH6ObX/gNuA1gP3jSc8ZOBrH4nBgX+BG4CGAXFHc XQeQ51OAC4HTgVirqDz5OwzYCzgIYNmzANqOwPnA5cBMYCKwBeAFeDDA4zWOhcOLDD5HoVDq c3C7hkvdKendS19MCaV+ndG9hBcLNWWgxTGAC1MKRNR5Xdp515l78VWoG26hX5tSOQQzUvvf ku9d5yrlBfnerTSDJioDEQZS64GJXqiDNzfag8AUz/f7fzchiqKFoPA4AOANiDf7uthAFG4L vAlsAMYAvNnzJtgf4A3Z2nJ4mLc/EIxH0JtV4M28svoGID0d4A2bgu9WoAh4HGA5Cpb/An8G KEiGAv2BzYA1znLgnlcmHGx80O2PQEXtY1pl9aUh3QU4k/URQKPomQyEAfI+FqCNAiYC7zAA uxToD5wMLAGs0Lse/pUA+aG9AlDU0Mg7uXgWyAfWALkA7VvgMs8X/bctvHsDI4FCIBuguP0p gkPgss7jgReBbQCKJIoU9vtVgO08CpgHWDsXnruBhRFcAJdjdTHA89JycR/87N/zQNAqKj8a mViG5w6NdZ0KPAXQeA5w3FOAswGe5+zPxwD72ihWtG7Vz6169AvhYD3xvWtdSkoKeUqB//Wi 1WkVfSYbpW16EGWgKRjIbit/wrLebeJ4X2541Z2NC+8YFUhNMRot45j1IahuA1XjgVXAF8C/ gOCNDkHPeKOztgwe3iR5M7fWCx570+sBfxHwF4AiYBegIuMxOwH4rHi2Fv8529EZKAA4E2St DTyLAM4iMD1orRFYDFRWH8WBA/BYFCgUUacBjwM9AdsG1nEUQBHANgSPlYlwCWBv0PD+zipr Xzfkrqw+N1IbxeUwgDdZCoifgAOBQcACgNYf+JGeiH0Hl/gnwNkXiiNrrMcel+LKGkUUuYtn 0+NE9kfcUoBiisa+UpTQOBN1DPAhcDDA8d8NmA8ERSTF3lbAPMBaf3iCfXkmksD+7gFcHQmn wWV9sdYfEfHKM57nkzUeu6sNwP014i+G+wtAMUXjectjNZINAJ9uPm4g7cRxrsVJmo6zcW1h Sc7ZjdQAPYwykBAMcBkvJcX7kRE/97wqL8QXixuz87zri71GJ0RbtRHNiwHeJOtqpajgcICC 4jWAN7K2QKxxGckab9arbSDi5sC9KIKpcCdE/JfCrcy2Q+KQQIZl8BcAvFHzBtcPsNYfHt6E GZ8FUIhZGwDPXKCy+oYjvQNgjcKA7W4PjLCRcPmhXQYw7WegP2CtPzwUNLzhVmSVta+q+r5E pRRzbwMO8AbAmaZdgeuBCwFrFBAUr9a2gWd/YBPwMbBVAH3htyLQijZE1dgoZlhvSqQkRceo iP8VuGz7YcA0gPxxTNjGEGBtMDxf2UDEZb3BvhyCcB+AfbkEsH1hHh4j1ioqz+P3DmSOPXZd uAhUWy9eT+hi0NNxAykQU3qKrOuaWy81ayXKQIIzkN1ads9uJ59ATE1EU/fAZ2Al5uovwK/2 hkJMvYQ4FVMJPobJ3rzgTaq2fXkaBY8E1gDjAQqFDCDWTo5E8IbEbw72hsiZKs6k4Bt22esm VsC/KBL+HG5l1h2JkwCKGt6kefP8CCgAuHR0NsB+UiyMAnij5o3nW+BcgMa2cSaLx6ysvpOQ fh9AY37W9xpA8fYscDRAY/84s/IB8A6wD7At0Bq4FmAbKrPK2ldVfbeg4hsBiszzgGOBWcBh wDXAjoC1d+E5GOgHpADsWzdgCjACoIiinQZMBaq6IFFcZwKV2S9IXAr8KZLpLLjHRPzknzM+ NwMvRuJ4LiwDToyEKZI4lrEckhe2sxVA0cTzciMwGTgF4DlJjAf+BtD2Bnb3fP44xStPjs4A WNYBOMafAIloS9go3Ei24P8LhbrUl4hjpG2qZways2Q77JN61UmVb/EBHYmL1EZ8Bq7blCuD bsqT/2ZX/uW1nluj1bVkBlLrofP3o44JwGwgC3gUWAfE2v6I+B7gDfGfwByAdjnAm+xMBmph U1FmIsDyFAUh4DiAxrZRMCwHOgAPA8xLOxvgzfYioBPAG3YYmApUVN89SHsNYF+5lPQpwBt5 MXAdwOPdDlDMXA3kRUD/9Ih/NdzhQFV2NjLEax/FSGX1UdgeA/wXYH9+BDjOWwObgTGAtQXw UDDMB1YBc4A3gFJgHLAQWAy0AUYBVRmFBseWfazM2IYXAHKVD1BUWXsZnpuBN20E3NuAZ4Hr gZ7ALQA5DxqF0gcARQX7fSdA/nkMjhF547nBsbsg4r8Y7iZgBvAU8D5gy7MfbNtzwEfAIoD1 0f0YYF00iiz66dJsvB/6fdjG179rSn80knIEGrKpMDz/ijhtqf9j1qxGEyd7vLg42TRKGSjP wA0Z0i8tTW7E+X4WPn0pOJEwKyv3F+bK3fjwbiifW0PKQMMzYG8CdT1SR1TQH5gHFAGxxrhe QDrAGxhvVPVtWahwK4A3Tjem8r4I5wKxH7IUxG0D8CbJm3DQqqqvEJkpXoLGmynr+wXALEE5 Y31dAd6wq2tVta+q+jhbsx1AIbUMqOjm1QlpFFEcm6B1QYDjRlEWK2CC+YL+tgiw76yvMuO5 wPpXVpYpkEZRR1FI/ihsYo3nMtEboDi0fbXnOMvST4FYmbE82xQ8h+y4kkfWnZDWqkfBxY6T 8Z+wmzMivLrrtARspB0TNs366cbzJ2DztUmJwACW9nriK+INOGtGY88g9wqWGEeeKA7LLXcU NMrnk9cRfknl9ZWrDrzmcUsLv7TzWvqa/4t8+NQSmoHIq2dORCPXAxsBXuN5fykAqFuoC+z1 Cd7Kzd5sKs9V91QrqOLNXNW9dq2hJTPAc9iexxQ+9FvX+slPMB/Dzc7SOnw6yKR2ah9et+P0 BO1cUDxRsNqw9VsRa+MTtBvarKZg4Po20i095M3OXwQhlYFlPZ4vL4SLJfu2oiq/KNVnk3kt sYKKWxysoGoPPwXVGyqowEISWERQHY+mUlBxQsEKKk4K1FhQ8aRoDLsNB6HiU1MG6pMBK5Ks cKKQIjizZ12bZvPy+PQ3OyvZeCBn1gh+a04ks9/wrFCyAoqzmPRbl+NiRRXbb8vRr9ZCGfBm pCCkIKLOxyc3E2cFz4sJYSM33ZZX7pe5jc2QPZ/p8ry153Jjt0OPVzcG7PWH4xcc0xrX2liC 6tYat0wLKANVM2BFkhVPFFIEp26bpWiqmpKky8ELGJdKeFEjaFZUMU2thTKQnSH9saB3FW5x 53FGyhNSRt4Iu3LzrfneXshEYcYKKZ6/3hIRZj70+pMoo1N5O3iN4ZjZ64+99lReqoLUxhJU FRxeo5WBWjNgL1hWTPFcJtIAR6fca81roxaM3Hi4F6WE4xY4OC9wDKuoCpDSErzZbfDcwRTM SBnv19f8gsRzYAKE1K0QUt8nEAdsF2/AVlDxHCZOAbj8x31V3PvJGeMMgNcmXqN4zVJrPAY4 PhRNHBvufeZqGfdxc3mPy3x23HjNseNZq+uOCiowqJaUDPBmywtTUFClI8ybs1pyMcCbjRVT vJBZ8OJWqwtbcnVfW5tNodFWjsO8zkU4E0ZEGCnBPqnncQbchaebz0swloLnqJ2Z4k2b+254 0+a1iGKQxvOYP+qxcSqoyErjGfnnGHEMCO6PoqCiy7Gye6XsTJW97tT42qOCCmyqJS0DVlTx wsVvfxRTvDmrJRcDdsx4AePFzCK5eqGtrTED2Zn4VW6anI/ZqNEQUj1YAU6CPPx7DHMK/8ne UvYmghrX3YAFrJiy5ytv1vaGzZszb9RWTNl4iileoxhvvzzAq9YIDHCcOA6ciaKgoogKiiqO GePtOAYFFctW21RQVZsqzZhgDMSKKV6seNGq6sGiCdYNbU5kzHgR4wXNiinrKkHNjwEHy3qH YG75QnyIj0H3UjyJYfBWBINnBebJs9n+ckyi9zwoqHhDpljiPdXeV62Y4s2b1ybG21l1eNUa iQF7LeEMFMcpKKq4/GdnqayoYv4aCSnk98wOvA2rqwwkEwNBUcULls5QJdPoRdvKGSo73U6X Nx39Fh/lp1n4stvKDhjVUVjWOw0d6sNOYUmPN7EJkNEPZ+d5b8pgdDJYUExx5sNuPbDLeTyP OfPB65IVUxRcKqhAQiObFVQUuEFRxfGxs1U8D2P3UtVYVKmgauSR1cPVCwO82VrYCxkvVlZU 1ctBtJJGY4BCmBc0XuDsTceOL90aX9hQRi0BGBiTJYPTjPwJD948GUJqp0CTlnrLekaewP6o 2AckB7IltDdWVPFcpfEGbgUVZ87tUp8VUzYf86o1PAN2nDguFFVWONG1y310GWa6zlCBBLWW xYC94VpBxS8HBG/OasnFAMeMyyIcv1hBlVw90dY6eG7UbhjJoyGYToSI4qyU9+0HdzU+PPGV UiPP3ZrrvYszmYWyvUnzOsSb4tzUFAAAIABJREFUsBVJjGeY4Llsz2k9r0FGExnHxI6XHRsK XvqDM1M2zs5osUyNjIOtpgwkKwO8iNlvfbxg2W+DydqfltpuO272psMxtTeolspJ0vQ7m08K z5KRaPDRGLQjMXI9vMb7I7gBy3pvIW7Cys3yyaP+LEDS9K2ShvJmyx7y5mvN3rQZx5szz+fY c5plfGbgUWsUBjguFlYsWWFF185M2Tg7pixTI1NBVSO6NHOCMmBnqXjx0nM6QQepkmZxzII3 n0qyalJTM3A+vrj0zJI9cIs6CDNQB6E9+0AilM0M4y70C+Lec0vlrdX5MrkZiahY6u0NN3gD tjdse02ieKI/KKRUUMUy2bBhO050CY4RXQoo+q1rx87mQ1LNTG8+NeNLcycWA/YiZS9a9iKW WK3U1lTFgH6Lr4qhJky/FMvoHbJkV9ws9kMzRmA/1P74wLW18yzeO/WMTEPcu3j45rsJ9vDN hmSON15rvCnbmzVvzPbaxGsSzYb9kP5vCgaCQsmKKjtm1mW7gvlq1E4VVDWiSzMnIAP2QkWX Fy97AUvApmqTKmDAjltwLCvIqtENzcANmdInLUX2xnH2xgzU3ri7DIPLH3x4xkGCiJoHiTDZ NTK5OFem/lNkQyS5pTn25ktaeJOmWUFFP+OtBf02Tt3GY4BjZc367fgxPui3+WrkqqCqEV2a OUEY4IWpIqigSpBBqkEzOGYVjSfj7cWvBlVq1qoYyOaXjywZhIdqDsOs0y4QTcMglCietipX 1kAgGPkegzDNceVTuFOy82V1uTwaiL0Z87yNtXhxsXk03HAMxLuOxIurdQtUUNWaOi2oDCgD ykBSMODckCF9U9JlaMjIELR4KO7sQyGidoTrLd3ZOz3EFNXreoisr+H5CgLrq4J8+fpukdyk 6GniNDLejTpeXOK0WFtSZwZUUNWZQq1AGVAGlIGmZ+D61tIjPUW2xlzfQLRma2AQsB0BncQX 9JZbgIqIqOUQTrMgrmbCnVlSIjNvL5Sfvbz6TxlQBmrEgAqqGtGlmZUBZUAZaHwG+Mu6rhnS My1N+mDZrQ8W63pDBPWBCOoHYbQ1/APKRFO85hlZhemRHyG2fsQC3jxs8vmxxJE5d+ZKTrzs GqcMKAM1Z0AFVc050xLKgDKgDNQLA9lccmsl3UvTpRuW2bpjM1k3iKVuEErdIZC6QSj1QHwf iKFuWI7z9wfyN5EwpJfNONGP5bl1cBejzGIEF6PcYjwMaUFKrvyYLbIRcWrKgDLQgAzUm6DK zpL38IE/0mur4WcblwQYPuCeW0XYxUWA+dxIfvx4JBKO1vW7NFTOX1NEwc2Tfh3ecyVQp+ei zlLU5qWh3lIvjHxMpx+N9d3I8yjQDzzMFw9mQzzqi8KvrxQ1hXFsGx/1I55lUSbM4yBPGN8m vTD9XjzTWR550KFoWqlXZxht8tKQ4rsIe3EhhIt9P8MGYZOHOlAPnkoWzgfwvBeWwaHVlAFl oLEYyOYrj7KkXbhY2qemSHvInnb4vHfAtaUj2tAJH8jOcDsjTNcL0894XC/4HkP/4WmILLOI 33PwD+KI16lf4V2Ozz+X6X7FMZbjWvIL/Euwz2mx7nMqY089ykCTMFBvgqpc6x3BdQIf94CV CyC+2uHYiuKULTtMTKXlgpFAMM762ViaDZf5gxFejsg//3tiMMb3B+LLigbimMmLj8RFvmj6 ZcsFEBVvZMp+uOwXwWW7zDrAdzOAiy6FZwkO5Asy47u4eP8uDv3mE2IpHCkAfT/LRcqwnjKB 58dF6/BFZVkZCMdoGutAerljIo55oCApQH1ERCOPkcK2hANpNg9jrZ+iEiIS7ygpXYKGz8PD IJeBUohJNWWgMgacbDxLCW9BzQy1lox0VzLx+coopZsiGSlw3RDSjLTBZ6INzsc2EDBtcP62 xWehDc4/btz24nCQtkjPQnw7fD7aI097lPFEUVrZoy3LNwX5ypkN00V5vu1+NY73G13UTfc3 fH5W44P8G9JXu2H5dcEWWTnB/3KHZDVlQBlIRAbsZ7s+2+bVmR3RDnMj7vYRd2XE7RlxsYDv QDuE2vvhEK4u1DehzEi4KEscXKc4fxUqNr4LXeGF0egQ48vcdN+P6aUUxkOjeC5u4im4gHp5 Gcd0HgMXUFxLJQUZUzAlloKKvPxIo5tqEI8LXQouasyfArHiuagptcwP6WP9mDVKZTm0h/KI /hTm9VxfIvlpjp/PO46Nj8R55RjHsF+H78aLi58H1bYwwywmeszZOgyFlBbjxtmpcxcJpWLQ UzAEdAEHAx2Mc5iW4qcxnxdmXuTz0/z89HvhQLxNjxfvhELecb1yTsSPOC9s0xhGmo1jmbjA icBPhJcWcW3Yug4/MYE83ugzDoaSnst0LxxxY8OGzNHgBv1eFOmNF884F7+oJ0oxCWz9dE2c uEi66+XFRG04LFdfdZVsnSIvZjhSlB6SEny2S/EeGhcnvcEHkq3l59b/DPBZSMZ7HlI6ulXe z1kipvnPS7L+DMRloBJP8Hj9a4h/Bl88RDbh2JvR3k2gZZPn+s9m4vvrcnAd4V6l9ciXg+tP Di48OXh74fpsX1A1RKu0TmVAGWhkBvyrbCMfVA/XcAycBDHXHeILIhSrD5IaypJUzAyl4lt5 mndj4s0pXVLx7dwPU6hBbkI18n1qviBEGALTS2cdEQEZTUcctEC0PMVnMMwyTqC+QBg3lt8J RNyA/LrjC0Q/vy1n87DOSBxumDHzgA3Hr9acnAzgHCvEOVmI828LXYQ9Nyacj3OKyEMeTnzm 4dzKR14vDjNG+fgSlo/PTi409qZiVzZtyZfNY/0XOycnMdpqZUAZqDcGVFDVG5VaUSMyQAFF ocVFFv4cvC3+dUJEJwjArlgSfDZn3VpvBoSzIZwJIQxeLub5I3GcVXFL/TRv1sTmRT4/zc/v zb4wLRBv0z03Jp4zNWX1Mc3O3KCOsrQqZnHKyuDu7s0Oefnhj7hMLxePu75XBi7jaf7EHT2R cMT9XRhZvFkuFuKckOfAtX6oC/rL8vgZvHDZrBpn8YKzbJXMvnmzgZHZwn/dcw8ekCSvpTqS lwqxkgbRAhQgvCXVlcKQI8WAt7SMJpRg4qsIzSnGklix59LP3YWhSLgk4ke4MF+KMDW1JVtQ hnSoKQPKgDLQgAyooGpAcrXqBmPgd4IKR+KOMm4l48bfCWXLVgioJS4DEZGGiVVvSYy/RNsM 5AHcW0QhxL2AUI9qyoAyoAwkNgO6VJLY46OtSzAG1q5dK/PmzZMtWzAPpqYMKAPKgDKgDEQY UEGlp4IyUA0Gpk+fLttvv73svvvucuKJJ0qnTp3kpptuqkbJirMsWLBA3n777bgZvvrqK9lu u+3iptnIbbfdVh544AEb9NzCwkLJysqqsF5muuKKK+Qf//hHuXIaUAaUAWVAGVAGlIGWxwC/ CPAhEllAN2BrYBgwAvgTgBW/+rOVK1eatm3bmueee66s0mXLlpmtttrKPProo2VxNfW88MIL 5vDDD49bDMLILF++PG6ajbzxxhvNiBEjbNBzIdBMx44dTVFRUbn4YCAnJ8esX78+GNVkfo5V ZMw4dhxDjiXHlGPLMdYvfSBBTRlQBhKfAb1YJf4YaQubmIH77rtPDjjgADn99NPLWtKvXz95 +eWXpUuXLl5cfn6+jB49Wvr06SMQOfLNN9948XPmzJFzzjlH7rrrLhk4cKDstttuMnv2bJk/ f77ccMMNMm3aNLn00ku9MOsfN26cDB8+XBYuXChXX321V0cpNrNfc801AgEne+65pzz11FNe /KmnniqfffaZcBnS2uuvvy4nnHCCpKeny8cffyw77LCDtG/f3ptV++03PuJIBMJQXnvtNc+/ YsUKOeyww7wZN5Zj22gV9cdL1H/KgDKgDCgDyoAy0CwYaNQZqqOOOsrcfPPNlc7iQAyZ4447 zmB/lXnxxRe9WSLOBEEwmdTUVPPXv/7V/PTTT+b44483Rx99tDeDNHbsWAOhZjgDhiVFbxaM M07vv/++V27w4MHeMSHozE477WSwRGg++OADk5mZaSC4vLRddtnFPPbYY56/pKTEdO7c2Uyc ONH88ssvpkOHDgaiykBwmb/85S/miCOO8PJdfvnlZsyYMZ5/33339drG/BBwBoLPi6+oP15i Pf7D2agzVM3iI6mdUAaUAWVAGUhGBhpVUO23336GoqYi4/JZSkqKWbp0aVkWCqNnn33WE0YU OeFw2Ev78ssvzTbbbOP5g0t+FFQUXuvWrfPSKMSsoNp5553LLTc+/fTTZu7cuV4+zHyVCaVJ kyaZHj164EkOpeb2228vi2fG1atXU7iYTZs2GSuoKPBCeLwtNth7dRUUFJhbbrnFUAhW1B8v Yz3+Y5sALtPqkh9IUFMGlIHkZUCX/JJ37LTljcQAl+q4STzWIEjknXfekSVLluDxUK63HMdl OeLrr78Wu8TWrVs3gUDximMvVoW/EOzfv79AfMUeRrBfS4YMGVIWf+aZZ8rQoUO98J///GeZ PHmyQCgJl/tOPvlkPOk9JBB3XntsIbahTZs25ZYHWe+AAQMkI8N/kDhmvrzN6ixbWX9sneoq A8qAMqAMRBngwxHVlAFloBIGuA/pX//6F3e6l3u45R133OH98o9iB7NLnoihaKFt2LBBWrVq 5e1JosCpi/HXfqtWrSqr4pNPPvF+Acj9Wn379pU99tjD+1Xfm2++WbY3ir9I/OGHH8rKcK8U 20ZxaI31rlmzRrhHi4IPS4bevrA//OEPFfbHllVXGVAGlAFloDwDdbvSl69LQ8pAs2Tgwgsv lLS0NMnOzhYs3Xl95OMO3njjDW/DOWd5evXqJVjC89Lw6zxPaHEGqzKjCKvO86yOOeYYr278 cs8TVmeddZZgf1RZ1dycjj1enoDba6+9vHjs0xIKr59//tkLs70jR44sJwgpxtj2V1991cuD pURvxq22/SlrkHqUAWVAGVAGlAFlICkY4BeBRntsArcM2b1PrVu39h6XwEcmvPXWW2W7ibDs 5m0Ix2yVt7n8tttu89K4FwozXGX58Cs607t3by/MPVesB78C9DalDxo0qCxfcA8VZpe8Tek9 e/Y0EEHm/vvvL8tHD2aZvP1X+NVgufhzzz3X4Nd+BjNOBsuJZtasWV663UPFAB+zwEdCbL31 1t4xZs6c6eWpqD9eYj3+wzjqHqqk+MhpI5UBZaAqBpyqMmi6MpCADFBQlXuXH8IN/uoZ6Ahv PxP3F3HprNy77dAAziBxVgrCp+xxClVxx2W24uJibzmuqryc+WLddj9WVfmZzqXCjRs3Ch8C WlE5Hh+b4b26g3XWpj/B8tXx66tnqsOS5lEGlIFkYEAFVTKMkrYxloEmEVSxjdBw3RlQQVV3 DrUGZUAZSAwGdA9VYoyDtkIZUAaUAWVAGVAGkpgBFVRJPHjadGVAGVAGlAFlQBlIDAZUUCXG OGgrWhADeMhmud7yl4PcH1WRVZUerxz3P/HZVGrKgDKgDCgDjcOACqrG4VmPogx4DPABoXym FY3v4ONDOvHrPjnwwAM9Fy889tKqkz5q1CjvnX18WCifMcVHN+AXfJ6Q4rOl8Cocb8N7WYXq UQaUAWVAGWgwBlRQNRi1WrEyUJ4B/jrwqquu8l50zJTrrrvOe4DmokWLvKet83lQTzzxhPfE 8+qkMw/ry8vL815mjNfRCN4DKOPHjxc83sF76TFfyqymDCgDyoAy0PAMqKBqeI71CMqAxwDF TpcuXbxX0zCCr3jp3r27J6oYxouO5ZlnnhG+goZWVbqXKfCPD/vkQz6nTJnixZ533nmCdxB6 T0IPZFOvMqAMKAPKQAMwoK+eaQBStUplIB4DeKin9zwom3biiSfKFVdc4T3b6ogjjpCDDjpI Dj74YJssVaWXZYx4WP/LL7/sLfsxqmvXrp6YwouXy73XL7achpUBZUAZUAbqzoDOUNWdQ61B GagWAz/++KP3qheb+aKLLpKPP/7Ye2XMtdde672X79hjj5X169d7WapKZ6Y777zTe8Aon+e0 6667enVwlsoa92cF3+ln49VVBpQBZUAZqF8GVFDVL59amzJQIQN8ijpeO1MunZvRueeJLy+e NGmSUHTddNNNZXmqSucmdD7lnMjPz/cEWvv27cvK9+vXTzZv3lwWVo8yoAwoA8pAwzCggqph eNValYHfMcCXIdtHJvB1LxkZGbJ48eKyfMOHD5fRo0fLggULvF/nVZZuC2VmZkrnzp09MH+s 8ZeEfNmxmjKgDCgDykDDMqCCqmH51dqVgTIGdt55Z+Ev+mh4abG3r4m/wuOv/2gFBQUyceJE Yb6q0r0C1fi3bNky2X777auRU7MoA8qAMqAM1IUBFVR1YU/LKgM1YGC//fYrE1Qs9thjj8k3 33zj/epv9913lyFDhgh/qWefRVVVelWH5sM9c3JydIaqKqI0XRlQBpSBemBAX45cDyRqFY3O AL8I8BeqrYDWQFugHdAB6AxMMMbASSzjHqcdd9xRZs2aJe3asbkibCcfj5Cbmys77LCDpKSk lGt0VenlMscEJkyYIB999JE8/vjjMSmJE9SXIyfOWGhLlAFloG4MqKCqG39aumkYSEpBRaoe eeQRb5P41Vdf3eDMjRw5Up5++mnvCeoNfrBaHkAFVS2J02LKgDKQcAzokl/CDYk2qDkz8Je/ /EUGDhzY4F3cuHGjULTxdTRqyoAyoAwoAw3PgM5QNTzHeoT6Z6DGM1Tc+B12S6XURNyyMOLK /G7A78cH89NfGqmDZSoMI83FUl6p8evw/Yzz62c566cbTPf8OAYXLG1aPJdLgczr/ZXz++UY 76VH8lg/h4Jp1pDsmY2zS6XRsOA5V34eR/AXCfj+aDx9TOOf70cYfyEnBATdoD8k944dK9K3 w1uS6hRIasoWSQttgVskKU6hhEJFKFyMakpQZxhuqefST7ggmG5KJOzFh4rBQLGYiFvqlIgp RTgFCBejXoSLiqU0rVi2/FYs4xYhf4AQBNSUAWVAGagNAyqoasNaspUZPjxV+mPPUWsgHUgB QoADpBWneG5pepqklmADj4O9SWncn+TDmLQyv42jy7LBcDy/wZFCUr4845xAHMPxygbjeKyK 8hn0SCJtNKjXIG/YzWqT1dYTNBRRYQgcNWWgYgZMIdLiw8iWaJqzBeduPja+5eOcKxAJ+X7G uYhzgFBKPk48xEueOO4mCedvlrum56IOPQkrHgBNUQaaBQMNJaiC9fr+k3Apoq0d7rvb5vru hkJH2nQNScciXJaKcevMCknbEke2hB1JyQxJBlynOCTFrR1JL/X9JZlwS3CrdlFHGmYrwiHo AN8VuqVASkjcEG7WEX+KA7+L+BDiS+GHG0KcCfiZ7iKO8czjpUfK2XhPELCc6wsBh36KhEgc XSsA6KcwYN4yf0RAxIbxFdrL6wsJ67duVLzYckHB4R2jAmECFkl7SzfOkqTidEjBjInnYvj9 MOLK/KGA349n/vLpfh2M89PihL1TC8Rj+JmPxy7vZ5xfb3AGh/V5edFOfjiCaeVneXC6e7M+ nAPCXwV+lrGzRtbP84BlrCGLZzaO+WnRMKQDZrGiM1b+lBbD8Wa3ovn8MtHZNc6Y+bNxQfeK K68UGdjxWWmVukXSMSOVnlqCj3SJpKe4IA3EhdigiLiPc47bz4Mxkc+Igx8qeAIbQpti20lH ZyDqje/3viAgzoYd74cN7HLDGaf9PCHmbMJx+ZRVC4RlI+LwaPxQjucal/71uP6sFyecIwWy XsZ+RVGnpgwoAwnOQPTKWteG/mPEe7hoHFnXarR8QzBg/CUSb0kksDxinPJLKOXSKyjj5/GX YMrlD9TLeLs840aWa4Jx9BvE2zy2HhNTRzA+FFnewbqNN/WUj5WaDYUpsmFLKtxWsrGwteQW t5GikvYIj8/dlOsJJiuerFBoCHa1ztozEBmXk1ADBAXFhSc28uBiBkiKAJ67DTm748jZw1vh 96EZkF0ZkGwZkupm4tzEU1KdDN+lHzAmU4zTBiq1Dc7fNlC8cN1oWBAnTDf45amDn3EaAK4x WZ6yRSW1tALU8Rva8huO+xvq9P0u4gRhB64xv8pPOStkwlwuYaopA8pAEzDAb3X1b3YjBmt2 nOhXWi8c+V5rv8oy3fPj66uXFy7DFfkxj44LCOqEa8vRjyubFxd0vRt2JM0TD8yDi7NDIeEd h4KCcXSBSLz1e+WZD/H0G9zUPTcQ5gW/LC3k56EwCMYxD8vavDbMfFYoOCl+ut0XwjxMKycy ImLCi4OfLpFainwuj4F9JaUQHCVhKSoIy+pFYZng9Q2HblaGmUZv1iL2sQkUet6MXNtWmc2q w9qZBmPAyFNT7XJfQx3Ekav3xaM90tpLSmk7LAu2wyULrtMeV58OuB51BjrhmtQJn2e4gMPH f0TixGmN9AGIH4D4qHmTdwwikvHbdTVy44i1qGM56voVcb+i/uU41nJMvi/BtWGx3Pn52mgF 6lMGlIH6ZCD48azPerUuZaAhGahIUCX0c6gakpBkrTsBZqgSn7qLhreVTsXdxKR2wzIoXEK6 QZD5riPd0YneEFE9oawq/5JsDPZzOUuQF5DFHhzzk4QL58kdX3PGS00ZUAZqyYAKqloSp8Wa lAEVVE1Kf/0dXAVV/XGJmkKYCeuOPWi9MaMFpFBk9YG/HwTYQPgHwt+xwiMaswFp84AfMds9 D9tM50m4YJYKrQoZ0wRloBwDKqjK0aGBJGFABVWSDFRVzVRBVRVD9Zx+7X4dJS0N4qp0a+gv CCwZhBmrIRBQQyoUW8asQitmADOxtWAmfgM0Q/45dVk9t0yrUwaSngEVVEk/hC2yAyqomsmw q6BKoIH8+/Dukglh5TpDMdcFkSU7QGztAtHVPk4r10CEfQV8KU5omiw30yN70eJk1ShloGUw oIKqZYxzc+ulCqpmMqIqqBJ+IB0Zsw9mtNKH4cdAwyCw4Dq7odVbxbQcvy40mMVypmDz+0TZ tPJLPDSVv9JUUwZaDAMqqFrMUDerjqqgaibDqYIqSQfy2v0G4vm/+0Bc7YMe7AtgNgvzWtaM wbOznM+xRDgRP57+WG79YrZNUlcZaK4MqKBqriPbvPulgqqZjK8KqmYykJfu1U46tt4bS4Aj sUQ4EsuFO0NsRe8vRn7GDNebmMV6Sz6D0Jo6lc8XU1MGmhUD0RO+WXVLO9PMGVBB1UwGWAVV MxnI2G5ct39XPG/rIDwV7hCIqyMhrnoEsqxH3Lt4PtZLEFefqLgKMKPepGZABVVSD1+LbbwK qmYy9CqomslAVt4NR/4xYk/MTh2HbMdCXA2JZjfrsDQ4AUuDz8qtn34VjVefMpB8DKigSr4x 0xb7ezX4AMPYJ6Xrgz2T7OxQQZVkA1Yfzb1uv20lJRVvd3VOxfLg9tEqzXy88PFJcQuf0Wdf RVlRX/IwoIIqecZKWxplQGeoolwktU8FVVIPX90bf/3+O+EF2KdjluqMwLIg30f4vITNf+SO qT/U/SBagzLQOAyooGocnvUo9cuACqr65bPJalNB1WTUJ9aBT8Juq8HDj8CM1WgIq2PQOH7G sUpoPsJm9nvklk8/8cL6TxlIYAZUUCXw4GjTKmRABVWF1CRXggqq5BqvRmktH8mQnnY5Nq6f C4HVxjumMd/jRc/3yJeYudJfCDbKMOhBas6ACqqac6Ylmp4BFVRNPwb10gIVVPVCY/OsxHtN TupfMGN1KTqIFz/DjFko4mbLrZ+9hJDrxSXmv3j31nhxidn65tkqE6db8eLiZKtelA5w9XjS XInFAM/bijald0Laa8bU6+cksXrfjFoTEVQnokvrgY3AZiAPKAD4pG0+rygZB/MfaDefKM5f tl0MPAAcDEwGrL0Fz4fANIDvyusFrAasHQ/PU0A34O8A67sSmA/Q7OegxA/KT3B3BMhbeiQu 6HAp7d1gRFL4z98tTbq1wQb2lBvQ3m39NhvsrXKulVumvJcgfeBY2PtprN820abbsLqNy0Dw OmL9dOP5a9Uy3pTUlIFkZsB+IOjyG2sif2tNZp4bsu123IJj2ZDHa4q6KRbHAbsAVgDZdvAp 4hRDFFAP28hI+A24hYG4JfBbsbQ//BRI8d61x1/PzQOS3x6dTr6ekZOw3Df4wDMl5NwI7cIn s7+LxzFMxouer8KM1cwm6mhQPHHmnGHrWj+bFszHsFrjM2CvLzwyrzk2bP10OU42Ht6amQqq mvGluROLAXvi0+WHgShNrCZqa6rBAMfMjl9wTKtRNGmyfIaWcj/QZcC/47T6RcRxps4KqjT4 OaN0ClAbI4/Nyybws/3peDlpewirrhd6wsqRg8SEpsuNI56ScMF1jfy4BSuSrHCikCJSAq5N s3k5JvSrNR4D9rNgry281tBvrzvW5bgwzZotZ8NVuiqoqqRIMyQBA1ZI8YPhLRFhKUkvWkkw cGgiL1ocM46dvbDB2yztr+jVF8ALwMqYHnJP0I1AZyAHGAHw8QGTgNrYkSi0c6AgZ7neDIST 1zthLnm5Ty4f/rS0kzHQJ5cgfI6ktj5Rxgy/Rdbk3i/+rFZD95HXGMKKKAopgrORev0BCUlg vP50AOz1h022okoFFdlQazEM8ITnyW8FFZcGCH6r5zJIO4CzAq2BDIDf+vklghdAtcZjgOND 0cSx4Y2d+6PyAe6X2gTYcbOCivlrfDFDmUQ3LsGNBzhDdVpMYxciPAv4I8A8JwATAHJSGzsJ hciztQ3wNA9BZXt071QKl6tkzD6Y1Usf6z1uIeT8W7q1+z8Iq0vktqkTbdYGcK1gsmKK1xWC 1xhH93A2AOMNUGXkizcfEM1rkB1THomfO4ZrdB3iCaCWOAzMQVP+CfAb7FRgAMDXNNgLIwee N6SuwBXAfsCBQNBYljekUYCtrzf8twE0foOi2Qv17fDPBN5iZIzxWJkxcYkS5IlOWDEVhp/g hly2Ox2wfWUefqu1cSoM6elBAAAgAElEQVSoQEYjmh0jjgGxBaCgosux4pjZ8bOiyo4vkpqV 3YzecL/U8Di9sst+TyPtWOBPcfJUN+ocZPz/9s4ETorifP/NfQiCeN+LeN+Kt0EgajTiLRoh mkii+f2jEoxR44lRMMQrKlHRKNEgifG+4hUVUIwaxYt4RggoGhUPEDkElPk/3955tRlndmeX ZWF3n/fz+W5VV1VXVz/VXfVOdc/s6+UWbtDlhj41We0/UI/99tGIcIWmwU3kXD2i96tu1a+u n5xc8PR7S+H8mqlOxpGsQ8X4whhta1gK8GGb/sRi3Im5hbBss0NVtlTLpCArLGflKWwAg+/p YjUxPZ/JDd1H9MtvR3CRIoANF6zYHMtG3vhU/KrgRc+GYIUXPZMwMFkzOTNRhzMV6WjDp0fS 4+ZR1FYPCtBf9AOfAukjnKisU0WfkR79iAOW7WNtNhqbpTPhvr1SvFNwVrdomw8++wg0eUrY ylXg/LEPJz/rvpVWqPiwOVh3+RFJizb7abXqN3rQesVS+P2qcKoYUxhbcKaYnG0NS4HoM8Yc xp6gxmdhh6rGktXrDjhBp4obBY8EsqavDaff4jlY4R/zGXsqZNJ6JL/d2IO4AcJpYmDjmo7r OtKZvHGoSI9PlYra6kmBGKBYhcJxyjpVrL7GKlU4VeFQ1VPz6v0wo3TE/xN7ifsyR2cl5VnB twH/Jri+a2udtWOXgp1ZFcRRa7xW+e7URclZe9ycNG/OY8DDdMdfkuyROybZvdfPkwvGPVlH J1/oTOFQMcYsryv6dXTajbIa+owxh/kixqoIa3TCMfHUaCcXrjcFpulIvG/BALtvkaP+VWmH iXCoDlX8doFTVVPjnaMjC3bCiXu+IG152cw6U5xvLL0TYvH4j0EunCkcLjtUqFO/FoMTA1bW qWJyj9UqnCn6EWJgWxKHQtUst8Z5DRQ4T4XGPX2tYAV6SeypIjsfq7SRRdIbX9IFTzB29tXq 1L664zV+6mcWmueeSAb3GpXMXXBacslT0+vgpLNOFWOMV6jqQNRlUAUrVIxLMT4xR9TqKUat dloGJ9xUDjlRJ/o7waA6TlwveDGVx3GsVD0gmIBWFR+LruJNsbrgUcL74nDxuMCy9VWmlH7k xzELB3heYh0eOy5nYThGsSoVnxAZ1GJwIy3IOlO+7uu3M8P5jU+B4TgR4lThTEVIWgxu4Ygp yWYFaqnAwA3bJJ3WOV2O1emaJzV55mZq7e+c5I1xIzS6MonW1Bg/GE8YWxhvWOFoLzrmecIv pUuJBmD5L4PvoaZ+nocVc55oMB7Fh7uyP9h5hUqqLedGxw4SV4lxImtTtMEK0gHibUHZJ0Rt bKp2+m5tdlxG+8QkzeDGoBhOEulsQzhbhOFQUS7KKmqrBwXok+iv6JtwmrIrU5EWjhT72KzA kinwh0kaFyedp28Djk6atRmux4D7aQT4Q7Jpr58lg3OD9I+Xx9biADGO8MEuxhnmUxwsW8NS gD7DiaL/lmiesEPVMDr+fjXz5+LMIs29WWk89psibhFNZRLiPBnUmHzDSIvJmMk560gx8MUg aIcqFKufkH4Jon/CsSKMT4KRFn3KPjYrUDcKVH4bsI++Dcg3KH8vx2orDQljknN63ZHkFp2a DH1iStEDnd3rXK2hjkwuGvduQT7jCONKOFWxGl5QzJvLuQLRb+FMxVxR42bboaqxZMtsh5N0 5BeLHP1Wpf1W8Hs+fFuvtsbF1KXIzjOUtrxObNGu7AQcE3YMcjHohTPFKdqhKtLRSzEp+okQ 6CNCHCjiEUbfRTll2axAHStw/th7koEbPpR0Wvtk/dr6memL681aHCDH6mr9QM0FyaXjeJ2i 0s7osWpapm3yk+SMXvskw8a9EVmZMMYaxlDPqRlhGkiUPst++K51s935tZau3necpCPyPlPh KtUHSntGrCt4/Fdb21Q7flJk505Km1UkfXlIYuINY1KOyZqJORwoBjsstiu3/HdZKJB1lMKp ij6LkHZlyy2LdjbmYzJOdBBTBO9jZo17BVjdrS/j24gz8wfLxpfu8SsfAw5LTtv9z0mb1sM0 Ohwlx+ok/QzwT/Qi+0XJgoXDk4v++XnSsuUANYR3MtfTG1Pjk7N69EkuGP9cvnExphCGdkzM toalAH0W/Zft0xqfBTvbrEBjUCBuBM6lMB7n5+s9lKj/8GIdcrb4Tf7QOE1Y1nnKxitzq//b X0X4ksYVmaKnKr5NZpsPGpfltw9SyD44dDeIfwiM9yj4/aKeYrIYJt4TWKn62GdkWuKbP1cr +pTYQ/zsm+Q09mP9xfHfWJwgNhJjxaWC9mA/EYcIXo7lcT6P+3kkWlX7qqpPu6b/MeAChWuL dwT17SmmCs6N88VY4ebVgu+zsRRsV9WJ5nx4W1XwJRs0Pi4TP1jx+rcze2ydtGjxOzlVce6f JrkcP7twjBrT7esG5fSDtLmvDtXjQfqNPuFldBxUfjMQh5BV/jv8UrpUaACWfymdV2Y+FTj2 LB4wTnH/8U4yHy5yoizzClVZMrlQA1CAiz574RdznoqlNYBTaxRNPF9ngdNQuPqR7bOanOjm KozjgRP0t4Idf6ztoYKBEfugMkidpWsUP0vgRIwWPxA4QDh8Owh9EyzpLsaKLQTOR6n6NlDe luJsEfZ2PtJLIQP0Q/ltAs6fyfde8aigHecJnIvTBG05Nw/tu1KsLq4VpdrHpF6qPmWlx7tH ISvbT4vtxftiiFhXjBQ4MbR1adsLOsBe+YOgcWvBsffNxBVdBvbb8RN1VH4EtJce8dEne8iZ QqPFrRn/yqr535PT9xiQ/O4JdGdMydJ88R281QAUoM+yfVgYzzWAc3ATrYAVaIQKrKJzwgFg 0mZlaGeB/UIcm8Yqv616lOIvif8IPiGGMfGzYpG1o7WxdzZB8f0Eq04TBI5HGIMhxy5mfGnj V5kM9rtOtBALBA5G2HRFOGZV9e2vfPYvZqOU+L0iGZzrM5n0norzqJ1B/XpxkggbqMhjoqr2 VVUf9bD6heOJjRBXi4sEq0M9xCDRT2AHijFipPhIPC42EtiJef6iMBzI8xR/Q9CP9FvYg4rg KNE3UwT7YluKv4qu4jUxS9AnEee4hba2Eh4WrCDcKbYR2Jri7+IzwfF7CWxrcbM4Q0wStwv2 4VzeFtn+12YJO6d3T728/qHIFeWcXouS075DXTi83cR2orfoK7RAZWsICtBX+T6j7+hD+pI+ 7Shw+Lkvy7YaFS67Vhe0AlagqSrw/3TicwUT25/EHwXWVayfxpJkV4XHCCYfVmlwJBi8MByb hWnsmz87KrrpN5tpDIfgl2JsQToT7ZeCifTfghWplQTGYMnkGzZZERyG9cRsMU2EMRlvLKqq b0PlU+d48aw4QYSR/iPB8Vil4hww9ilsQxelrSIGi6yDhsND3VW1r6r6tGu6KnePwjUEuh8v LhG7iacFjuNqIoyJ5WOxZz4cnc/AsTk/n4YTxOTD47FDxQ8E9Yazs5XiZ4gBgmNdIdoLJqnt xbvi9wJH6teZ+LmKFxrHwmmj7rdEOF2k078VYqi4Q3COWkFKf4uPSbG/4Lp5QtAG2nixoB1V 27z5r8stWgnXqGTBtq0uSU75zmkl853R5BSwQ9U0uryzTpNBjoHbZgWWpgJMvBX5A1ylsF8+ XhgweeK03CaeFHsIjAn4RiK1tA20XwdxtzhdMBH/TWAV4jMieZumkLIVIpuuzXTSZ3Kuqr6u yscR5FxuFOeLYwXGfh+IgQLH7TGxjqgQs0TYe4owaXOs/4k5AufjGrGzwIGoEKXaR16p+pSV /vjkIoWHiYdJkO0kxggcT3R/UIRxnLPERDFIUBZHBXtOkIZjQzkcFpyijwTn0V2Ena0IDg/X ADpsJMIWKsIq4jwxNRPH0coaDi1O4K8FffUbcY+grt3FMDFD3C5eEX0E9rk4WTwrOM9xgtWt +wUaZ9uizSLWtvUAPfJrJZoVydW6ZT69fauTk1/tNkRlipcrurMTG6sCLZfyiXEz3CD4lFCX trYqGy4YJMIYGH4WG/nwxwq/EtyYJwhupLHiUrFIYAcJBga2aes/BFZVfacqf5u0VOWf5xVc JtoIBsCsXa2NpwR5vxQ9xWTBYPCewLYTDAAMXPcKJgAGKaxU+6qqr3LPync/jtQGgwjHYnBc TZwnGJiWhqE1/c15FNrSuh4YiPm0zABuW7YKDNXhuY/eF0+KiwWTbqExKYdNVYQJ8tFIUMg9 Hg7AmorPF/8ncAK2FaWMY3YRuXwB7qN/iZXFXMFKUNgKikwSTOzkZw2nhvu0qvoGKZ+JlGON EThRjCXXi7VEtIE6+oj9BW3IHqudthcKHAZsC/F3MUEwLnwq0CK7jzZTp4v2rV6QV1hfjHMz VI76mosjxJuip9hQ/EeEPa0IGmPvio8FemKMc2FoNlgcKmaKtiJrjDlhsxWhXTW1Cu0wRXyR 35Fj4rx8T7whZomw/yqymnhNcO3FeXPdvCrCOLdWsVEibCaH6bgSed9OXqFNv+RXu6+aXPOv i5M5Id23izml8SvQcimf4guqf686PEZH1XWUOFowEGStlza4sR/KJHJTdRD3ikfFWQJnYlVx mmBAuUaQzuA0WvxAPCV6iWL1KblWL6lerP12EKeL7mKsYPBk4H5E/EmwDP5zcbDYU1TVvlL1 LdR+2B/EJNFHMCFxzueLtQUaMDiF86honRnn9iOB5oVW19dD1L+bIh/EhsNlqsBXOvq+AseF e2mUWF8U2opKmJ5P3ErhzQUFPtH28fk0HJd3xR0il08rFeDM4zQwsWJTxVzB9f6OyLalQtuU I52xpYv4VGBdBRNxVfX1Uv7LAmcFmyKov5PgPhgjMNo8VXBOrcW2IqxCERwaZmLGNO6bU8Xt Iqyq9nE/l6qP/f8pGAOolzHlLnGuuFBsLxhvska/haFHC4HzVWhnKmElsZGYJe4TWWPsXVLD aVpN0AauKxwhrqmxgjGNfo7jbKL4nwVG2drbGTt10Q99jkxyzVonzXLqL4WJwmbNdfz8dm5R Wx2lrR4JtlHvtktaNOuc9N/2qOS6CehsswJLrMAvVcMrYoo4JV/blgr/mo8PVsgA+YD4n7hc tBRYDxE3Q5qgPxuLs2MjH66l8DLB4BuDcT4rHbi/FxuZ8DDFn8ls91ScgY2b8RbxKxF2pSLX 5TdGKSxWXzOlv58vUxjsr4TYP5vHgLBArJtJpP17i33EPzPpayjOIMHAVqp9VdVHVbuKvxCR fV+MFycINB4uGIzuFGEMyg8LJhPStxHYCuJ6MU0wiO0ksK3FDeLX4r/iecE+TD5sfyb+kN+m HQPFOJG9HjiHCwU6PCuOEbRjgugswnB4DxH011DxP/Ge4NqgL7C7Rbc0Vjl5MBDTZs61XT6d Nj8uSL9RrCiKGZNPsf25Fri+Obc7xOoCO1kwAd4qJovTRD/xpnhZ7CCaknEdcR9gHcSHgmuZ +3aIwOYLJmSMiXCOoH+w3cV2aeybP/Qj11Axu1iJV2YyeinO/dlJtBDnizsFdop4WnAtbSTe EnsJjGuQfOwIQbsZn3qJUvVdpbxRAuMcqftI0VpwjYYOOyr+uUCPrgLnbmPRXrD/tQLjnvqt ID1oqzhWqn1V1cd+q4l/CdpQaDhi3FthBypC39AX3Ftcy6HdMMVpW9gjivw0v0EbPs1sv6v4 Zvk8gjfFLmJXwb2FcZ8xpmDZONvoT7sx7iGcKOxYcUsaS5IXFB6ejzOufiTQnWP8W4RxfWTb PVXbO0dmLUOuH47VUTAOdBNcs71FX9EQ3sd2Gyvfj8vl+4y+ow/pS/qUvqWP6et6NyZSLmIm RJyjaWJjkb2BRmt7pugpthCviQMFtpv4Yxr75g/1jP9mc7EYg8P0xVIqnRKO8ZJ4SMQA8mvF rxFh6yiCiNywE8SeIuyXiozLb/xTYbH61lI653e74JypeyWBnSTGCNrNAHiCwGLAqdyq/PuU AvJXFHRgGIPEq/mNUu2rqj52/Y0IbccpTv9gj4v9RJt8XEFqT+rvFYKB6ULBcTHO/y7B4Hik +FR0EfTrQsE+9POd4j7RWqABx1lTbC8+F2jyfZG9Hn6h7ZcFE9u+Yq7YUKApx8K4qElfQ5wo nhO0cRPxujhGYO+KrcT6YrY4QNBmJjj6f0XxkcD5qRBca3eLQiu1P8ecIfYWTJz0+QMCw1Eg jzYfLBYJ9NxJXCWinKJNwvroLOkztH9FDBEYOkV8vuIPCvp6pjhHhN2myKWxkQ9r4lCxy00C x/5tMU10FxjXJ8fF2ZkjLhFhmyvygWA/2rSnCCtV3wYq8KLgOqY++noFgf1IUBd5C8RJImyg ItwX7wv27ySwNwRjU5bnyZBV1b5S9VXuWTnW3aUNtD1f/FbcIq4Tq4uwAxV5RrwpaPt0sYPA hgn2CztIEdpPP3O9Xy7Yp7PgfuT+C6O+XUT2/uc6GZsvkI2TxPXRM593gEK0miTQcluBHSrQ HP0+FGiAcQyuq7CLFcm2e6q2d47MWoZ2qBqJO6b+517rK3qL7UQ3wT3RUTBeLBOH6rs6MBd1 XOw4LUxi2RtotLavEGEMONfGRpGwh9LGF0knaUfBzZ41bm4GSPa7SswStGOEuEiENVNkkegq PhYxYCiaCjuBiKxUfd9R3gxxlGAgYEB5WGCcH4MLehwvPhHHCjprisjardo4LZugeH/xqeiX Ty/VvurqYwLYSqwhJuXraqGQ+toL9j9LYBuLr0RbNmTtBBPcSuJLUSHCxijCedOv1EWd2G7i P2mssu0P5uPbK8TxWjm/zX5MGthL4odprPIP18Pm4mzxl8qk9JPpo/k45Qfk4wQnitCdAZzz 5ZzuFmH0LTcLffCvSFS4imCSWyGTRrTU/mcqL+sYccNxI3KNXyauF2FcN3FenO+kyGhCIdfO dqJNiXOer3T6YC1R2AcldqlxMgNiN1FsQFxP6bSx0LieNxUtCzO0XV19qxXZh2NvIrinCo36 NihMrGa7uvZVVx/9sY3oKppVcSzyqKuYDtndOC+0DCumQeQtScjExrVSaFw7W4sOhRlLeZt+ pU30IWMB1xnXe2/BeNNI3I3Gfxr0Vb7P6Dv6kL6kT+nbGjtU1d0wqrMsY6IdJZ4QH4k/i6Gi 0N7KJOBgFDoUZP9NbCmY+DmxVwQ2SDyWxor/4YZDHOxJ0UfsL+aKmNAVTQe3hQqnCfIY2MO4 QWMCLFXfNSrTRcSxOF8ma45BGxmMyEMTBqX+4kyRbYM20/ObTETGQPdXsZWg3U8LrFT75imv qvreVf7aAo2pG7jRSe8kzhC/EFiFoNwXAqPuIaK7YOB4VoShz/2Cdn8ovhLYbFFs0iBvqviE SIFVaPv1TBrXD0bfoGdLcbC4WWAVgvSw/yqyamzkwwqF2TonaBt+J9B2ugjj3NBwTiQorBDF 9r9O6VkdOHf2i+Oja9gCRV7Lb6APN2VTsxk6YajO/lddgSXI/1z7QjF7p1ii0uivcPgLi9Sm vkWq5M3CivLbVdVXYpdaty/qw5F9OTaqCBm/uL+qM8aKrJbZ+6u6fWuSzz1V7FrhHpxYk4pc 1gosTQWYVOrCmKTPFUwwJ4qjxUGi0PD6wpjgmJgK7UIlHC9+Lybn42yzQlHKOH7vTCYDwlTB RP62qBBhFYr8R3wpGAzWF2EVijAZVlUfn2A3E2FTFcHxYXDpJTqLsCmK0AaOw7njiIV1VeRV geNwq/hYoMnTIqxU+6qqj30fEv0Ejs5Qcb9oJW4T94gbREwchKuJFgKj3FHiM4FGtJN8WEeM EBiTxZIYx10zU8Heiq8r3hJTxXfFnuJOgaEVxw/bRJGsVqTjDGXr3EjbPQTn8g8R50G4nsCp zlqp/QuPjbM6R8Sks6RaZNvQFOJck3Obwon6HK2AFWg6CjSvo1M9XPVcJVhdeFCwKpB1HrSZ 2qH6iwPRQRwmnhQYk1s4YC8q/oTgkxQTIXHAMSll85Rxk9g/X2BHhd0FbblP7CY2Fu3F6eIp gfF46BiBDky+OBLkVVXfGsp/TOB0tRAniocFEwQ6XCEwVr6o7w7Bp6vnxE8EdoQgf5L4nthQ nCqojzZCM1GqfVXVp93Sd5hwjFiF+qPYS9woLhAcj3MIe0cRHL+++YQfKzwgn/aewv75dJyd VwWOTFX2pTLbVVUgn0e/UHcbgRP0ZzFTYLeIiwQO0wyB/V0cLdoKtKGvHxFZo8yeYn2BlvTF 6mKs6C24zjCOO07kBM7RIQIrtT/pewvqxQ4Ujwr2t9VcgSHaxQ5VzXXzHlagwSgwe/bs5Kuv vkrbS8i2rTwFcC4mi6mCSfBxweOhXQUrEdhowcTGp/r3xWMCxwHDwZiWxr7500PR8d9sLhbD YZq+WErtXgJtrTpwunAc5ohLRNiPFKGtL4sF4iQRdpMi5L0taDfOG7aBwCFkH+p7QKADtrn4 QLAfjsOeAhsimJgLoa6q2leqPu2WWnP9PUcw8eNYnCluFPeK3UXWcKA+Fzh4tH1bgeGEfCxe E+SfJTD69d9prPLP1grQAasQH4o/ie3FWyIsez2spUSOhfboOFCEVSiCHkdGgsJ1BO14V3BN 4eSE40baVgIbIXCI0flu0UJgQ8V8QR0cj+sLwznKXkul9h+pcuzP9T1FbCOwy8TgNFb5h7q3 y2/vpBCH1WYFrEDjUYCxlbG5o1hddBPc871FX7FcvXz0zjvvpHPLSiutlOvSpUuuffv2uU03 3TR377331mk711577dzEiRPTOgcOHJhbd911c9OmTcvdc889ufXXXz83cuTIOj1eXVRGX+X7 jL6jD+lL+pS+pY/p62ViHHxLQWOKGQ7VzwUOBpPp0jBOfhMRE232GAi0QTYhE19P8ZUy2xGt rj7ELyY49a0WlWRCJnceGbbMpJUTLdW+cuprpgN0FTgAbao4GP1XrF/YB4dplSr2LcxqpYRw JAvzCrfXVQLnUY7F+RZrZ3Z/Vkc7ZRPycc4BHTjXqqzU/mtqp81Eue2t6hjOswJWoGEqwJjP GNKgHKr58+enPohWi3JDhgxJnauFCxfWhV+S1vH222/n4hgdOnTIvfnmm2n6gAEDckOHDq2z 49RlRerD5dahqu7WCIequnLOtwJWwApYASuwvCrQoB0qHJIxY8Z87VC9/vrruf79++eGDx+e 69mzZ+qvPPDAA2mcVaYf/vCHuY8++ihNv/TSS3NXXXVVrm/fvrm11lord8QRR+TmzZuX5h10 0EG5SZMmpeWbN2+e23HHHXOXXHJJbtVVV8117do1d9NNN6Xllqc/usAarEN1qBq/w/J6h7hd VsAKWAErYAXKUKBBOlTXXXdd7oYbbsjhFG2xxRa5Cy64IPVtnn/++RwrSr17987hSC1atCjN v++++3Iffvhh6iCdffbZadmTTjop16lTp9ztt9+ee/zxx3MVFRW5UaNGpXnxyI9HjG3bts09 99xzuenTp+cOOeSQ3HnnnZebMWPG8uRLpW1RX9epQ1XTR09lXGsli9xZMscZVsAKWAErYAWs wFJT4JFHHkm0cpRoRSmZNWtW8tJLLyVyntLjffHFF8ltt92WrLzyysncuXOTESNGJD169EgW LFiQbLjhhskzzzzzdbu0KpUcdthh6fbBBx+cvPFGvCZdWUSrWgn/O1rOVrLKKqskHTt2TLRK lXTu3PnrOhprpD4dqsaqoc/LClgBK2AFrMByrYAeuSWtW1e+PorTtO222ybjx49PHR6cH5wp rF27dsmECROS4447Lvnss88SPdpLHaI4ObbDVlhhhdQBi+2mHhZ7obqpa+LztwJWwApYASvQ aBXQN/3SFaSXX375W+eIk3XhhRcm999/f/L+++8ngwYNSlecoiCrXLbiCliZ4ro41QpYAStg BaxAo1Fgzpw56WqS3mtKHSYcp/322+9b58cjvG222Sbp1q1b8uWXXya33HILvwPxrXJO+LYC dqi+rYlTrIAVsAJWwAo0KgX0G1QJj+jWWWedZPTo0cmNN96Yvh9VeJKHH354MnXq1KR79+7J lltumb5L9eKLLyb6PanCot4uUIDfKLJZAStgBayAFbAC5SnAQgTvH/Mbfe1FB7Gi4K1rXkS6 rTGs6EyePDnRD3ImLVu2TF9i5/0rfXtPp9d4jJfnZYeLT8RMMUvMFnMFP+T8pah8c1+R6swv pVenkPOtgBWwAlbACjQxBXjkF7biiviLtuoU8CO/6hRyvhWwAlbAClgBK2AFqlHADlU1Ajnb ClgBK2AFrIAVsALVKWCHqjqFnG8FrIAVsAJWwApYgWoUsENVjUDOtgJWwApYASvQ2BQ46qij 0h/61L+dSb/9p38dk+hfy6Q/5sm57rLLLgl5/OAn71Dxg56nnHJKon+unP7a+iabbJL+RlVW l3322Sfp169fNslxK2AFrIAVsAJWwAoUVYCFCH5yvKNYXfD29nait+grlrv/WVesQfzT4zPO OOPrLP7X3kYbbZS77LLL0rSdd955sX9orH9Vk9M3/XIPPfRQmq9/R5Nr1apVbuzYsen2tdde m1tzzTVzn3zySbrdEP7QV/k+o+/oQ/qSPqVv6eMaLTrVqLAqt1kBK2AFrIAVsAKNTAH+1x6r S3KQip7ZZpttlv5vvvxPDSRyuJJTTz01GTBgQPLKK6+kq1fXX399wu9dNVXzzyY01Z73eVsB K2AFrIAVyCvAv6HhV9F57BfGr6nza+nz589PHn300fRHQXv3ZjGn0s4999z0X9TgXPXv37/o L69H2aYQeoWqKfSyz9EKWAErYAWsQIECw4YNS/9PH6tO22+/fbLeeust9g7UxIkTk4cffjgZ M2ZMMmXKlGTmzJkJP/gZxo997rXXXum/tOnTp08kO7QCVsAKWAErYAWsQLUKNJp3qLQalfv4 449T5s2bt9hrT4XvUJFJ+RNOOOHrcnK4cu3atcsdd9xxuYqKipz+X+DXeQ0hop72O1TVXu4u YAWsgBWwAlbACjUiw0MAAAaYSURBVFSpgJyh9Ft8fJOvnH8rs/nmmyc8GsT4tt9Pf/rT5Pjj j09GjBiRdOrUKRk8eHCVx2vsmX7k19h72OdnBayAFbACVqAWCvDu1Ny5cxOtPCV33XVXom8A fv2e1OWXX55Mnz49Oe+885IWLVokV199dTJ8+PDkhRdeqMWRGscudqgaRz/6LKyAFbACVsAK 1KkCxx57bPobVfwe1aBBg5K99947Ofnkk9P3qFiNuvLKK9N8DrrbbrslRx99dKLHf+nqVZ02 pIFUlv6r5QbSVjfTClgBK2AFrMCyVoCFCL4h30a0Fx0E/z24s1hZ3Kb3hxTYlncF8j8Bcbja +YmYKWaJ2WKumC++FItEWeYVqrJkciErYAWsgBWwAlbACpRWwA5VaW2cYwWsgBWwAlbACliB shSwQ1WWTC5kBayAFbACVsAKWIHSCtihKq2Nc6yAFbACVsAKWAErUJYCdqjKksmFrIAVsAJW wApYAStQWgE7VKW1cY4VsAJWwApYAStgBcpSwA5VWTK5kBWwAlbAClgBK2AFSitgh6q0Ns6x AlbAClgBK2AFrEBZCtihKksmF7ICVsAKWAErYAWsQGkF7FCV1sY5VsAKWAErYAWsgBUoSwE7 VGXJ5EJWwApYAStgBayAFSitgB2q0to4xwpYAStgBayAFbACZSlgh6osmVzIClgBK2AFrIAV sAKlFbBDVVob51gBK2AFrIAVsAJWoCwF7FCVJZMLWQErYAWsgBWwAlagtAJ2qEpr4xwrYAWs gBWwAlbACpSlgB2qsmRyIStgBayAFbACVsAKlFbADlVpbZxjBayAFbACVsAKWIGyFLBDVZZM LmQFrIAVsAJWwApYgdIK2KEqrY1zrIAVsAJWwApYAStQlgJ2qMqSyYWsgBWwAlbAClgBK1Ba ATtUpbVxjhWwAlbACliBQgVySijFosLC3l7uFaDPSvUn6WWbHaqypXJBK2AFrIAVsAKLKZCd iJmY7VAtJk+D2Ih+y/ZlrRpuh6pWsnknK2AFrIAVaOIKZCfgmJS/auKaNMTTp8+i/7J9WuNz aVnjPbyDFbACVsAKWAErEAowGTMpw5ci10ym0Lb8K4ADRZ9F/9GXtTY7VLWWzjtaAStgBaxA E1aAyThWNpiQF+b5gcJOYkWxgmgv2opWgjnXT4YkQj0afYTTRP98IeaKOWKW+ExEv9GH0Z/0 bY3NDlWNJfMOVsAKWAEr0MQViEdDTMCxMsWkPV8wabcWLQRGmQUi0uxQoUr9WfQRfQDzBA4V IX1Fn9F3sVJF+ehfRcs3O1Tla+WSVsAKWAErYAVisiWMyRqnismayZmJOpypSMeZYoWKdD8O lAj1aPQT/cBKFH2EE5V1qugz0ikDWYeKfcs2O1RlS+WCVsAKWAErYAW+ViDrUDEh4ywxp8a8 Gs4UkzcOFemsTnmFSiLUo+EgAStQ9FPWqeLxX6xShVMVDpWyambR8TXby6WtgBWwAlbACjRd BbLOFCsfOEk4VOEsxeM/HKlwpiI/yijLVg8KhEOFg5t1quLxLA4vzlThu1Q1Wp3iPOxQoYLN ClgBK2AFrEDNFCh0quJRXqyGMGHzmC8e9eFIQZRT1FYPCkQ/0S84VeE4EcbjPkK2s4/8tFkz s0NVM71c2gpYAStgBaxATNI4R0zC4SSRzjbEI0DCWJ2iXJRV1FYPCtAn0V/RN/ECenZlKtJi RYt9amR2qGoklwtbAStgBayAFUgnaBwjJt+wmLRjhSrrSMXKlB2qUKv+wnCosv0TjhVhrExF WvSpHar66yMfyQpYAStgBZqwAjHhZidg4oADhUOFA5V1prTpFSpEqEeLfiIE+ocQB4p4hNF3 UU5ZNTMvPdZML5e2AlbAClgBKxAKZFecwnGKMJwpymbLxb4O61eBrKMUTlXWwSINy5arTCnz rx2qMoVyMStgBayAFbACJRTIOkyF8djF820osWxCHKWwiGedp2w8ytUodAfXSC4XtgJWwApY AStQrQLF5tZiadVW5AJ1pkA4UdkKi6Vl8x23AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbAC VsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbA ClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApY AStgBayAFbACVsAKWAErYAWsgBWwAlbACliBxq3A/wf7XtEbk5hacAAAAABJRU5ErkJggg== --------------090008030607020607050607-- --------------050809080201000300000409-- From pkyzivat@cisco.com Fri Jan 22 15:51:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F9C3A68E9 for ; Fri, 22 Jan 2010 15:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtWCZ-e6ccnZ for ; Fri, 22 Jan 2010 15:51:46 -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 47E5F3A686A for ; Fri, 22 Jan 2010 15:51:46 -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: ApoEAEXIWUtAZnwM/2dsb2JhbADCfJY5gjABDoF9BI4A X-IronPort-AV: E=Sophos;i="4.49,327,1262563200"; d="scan'208";a="81694597" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jan 2010 23:51:41 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0MNpfK7007815; Fri, 22 Jan 2010 23:51:41 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 17:51:40 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 17:51:41 -0600 Message-ID: <4B5A3A0C.8050304@cisco.com> Date: Fri, 22 Jan 2010 18:51:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59B21B.7040405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jan 2010 23:51:41.0150 (UTC) FILETIME=[D82E07E0:01CA9BBD] Cc: martini@ietf.org Subject: Re: [martini] User vs route authentication (was Re: Requirements - rev1) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:51:48 -0000 Dean Willis wrote: > > On Jan 22, 2010, at 8:11 AM, Paul Kyzivat wrote: > >> Dean, >> >> I don't think the points you make about security assumptions have been >> raised before, and they are important. >> > > Thanks! I try to say at least one relevant thing for every three crazy > ones. > >> OTOH, I surmise many of those that are requesting this work may have >> more limited expectations. Specifically, the argument that "the PBX >> *is* the user" may indeed apply in the case where the PBX is itself a >> B2BUA and does all the identity management for all the numbers it is >> responsible for. So perhaps the registration model would be applicable >> in that limited (but large) scope of applicability. > > You have an excellent point. > > If the SSP were a traditional proxy/registrar that is authoritative for > the domain and the PBX were a multi-user telephone adapter with > credentials for each user in the domain, such that the PBX could send a > unique REGISTER for each user, then we might well be having a different > conversation. This conversation would be about ways to reduce the number > of REGISTER messages required to effect registration of the PBX as a > contact for each user. So we might be talking about "multiple > authentication", perhaps extending the digest-authentication model to > allow a separate authentication header for each AOR being registered. > This would preserve the property that the proxy/registrar has > established an authenticated relationship between each AOR and its > Contact, a property that is fundamental to REGISTER within RFC 3261 and > its current kin. Such an approach would clearly work reasonably well > within our current security assumptions, although it should be noted > that it does not prevent "identity substitution" attacks in the PBX. For > example, if the PBX chose to claim that a call is from Bob when in fact > the originating user is Alice, the SSP has no way to determine that this > substitution has been made. This is a fundamental property of a shared > connection in SIP (or indeed, in multi-user systems in general; how do > you know this email came from me and not my sysadmin?) and there's not a > lot we can do about it short of requiring users to provide single-use > keys for each transaction (the equivalent of me signing this message > using PGP). > > If we scoped the applicability to such an environment, then I'd be > willing to accept that REGISTER can be used for a domain, at least to > the extent I think it works for an individual user (I think REGISTER is > deeply wounded and we've had to put a lot of ugly bandaids on it to keep > it from bleeding out). MARTINI could quite reasonably define an > extension to REGISTER that works within this scope. > > > However, our discussion recently has centered on models where SSP is NOT > authoritative for the domain in-question; rather it is just one of many > possible relays that might be used to reach the domain-authoritative > "PBX". This model potentially allows SSP to make different security > assertions. For example, SSP could assert 1) that SSP is transitively > authorized as a route for reaching the domain of pbx.com, and that 2) a > request exiting through SSP comes from some user in the domain of PBX. > Note that this second assertion is not the same as SSP being able to > assert that a specific user in the domain is involved. In this model, > only PBX (or perhaps the user itself) can make assertions about specific > user identities. Yeah, more or less. For "names" what you say seems right. For "numbers" the situation may be somewhat different. In that case the SSP actually owns the numbers, and is retargeting incoming calls from sip:NUMBER@ssp.net to sip:NUMBER@pbx.com. When requests originate from the PBX, the SSP should be verifying that the claimed originating number is one that it believes to be assigned to that PBX. Of course it still can't tell that this is coming from the precise person assigned to that number - but that is because it has no notion that there *is* a precise person assigned to that number. As far as it is concerned they are all assigned to the pbx, and if it can verify the request is coming from the pbx, then that is enough. There is another part to that however - once it has satisfied itself that an originated request is valid, it needs to re-identify the source as sip:NUMBER@ssp.net. Depending on how it does that, it may need to be a B2BUA to do it. Thanks, Paul > The fundamental security question: How does SSP prove to others that it > is authorized to route requests to/from the domain of PBX? We don't have > a security framework for this in SIP. This leads to the "alt root" > problem we recently discussed. What keeps a rogue node from claiming to > be authoritative as a route toward a domain? For that matter, what keeps > a node from claiming to be authoritative for a domain itself, rather > than just as a route toward that domain? > Let's start with this second question and work backwards. Our > fundamental security model (when we have any security at all) assumes > that the node that is authoritative for a domain has in its possession > booth the public and private keys needed to cryptographically assert > that domain. This understanding comes from the basic references of TLS > in RFC 3261, and is echoed in our various documents > (draft-ietf-sip-certs, draft-ietf-sip-domain-certs, etc.). So if we make > a TLS connection to a node, and that TLS connection uses at the other > end a trusted cert for the domain in question, then we assume that the > other end is trusted to assert identities within that domain. RFC 3274 > provides a transitive mechanism for assertion of identity in the context > of a SIP request message that is also based on this model of certification. > > So what we need is something like RFC 3274 for route certification. This > has to allow for route redistribution and aggregation, since there might > be more than one relay proxy between the source and destination of a SIP > request. Adam's draft-roach-martini-up-00 defines a possible syntax for > a "route" (using XML), as well as a means for advertising a route > (PUBLISH). One can readily envision adding a signature to this syntax. > It's straightforward then to go from a single-hop route to a routing > vector, where each hop in the vector is signed by the next hop, > providing a fully certificated transit chain to the destination. > > -- > Dean > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From spencer@wonderhamster.org Fri Jan 22 16:45:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA6153A6821 for ; Fri, 22 Jan 2010 16:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=1.332, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 ryDJQotRN7Lu for ; Fri, 22 Jan 2010 16:45:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 106D63A659B for ; Fri, 22 Jan 2010 16:45:27 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M9KLu-1NfffW1iZC-00CgZE; Fri, 22 Jan 2010 19:45:10 -0500 Message-ID: From: "Spencer Dawkins" To: Date: Fri, 22 Jan 2010 18:45:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DCE_01CA9B93.032C4090" 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: V01U2FsdGVkX19LFG8mYwe+HDy0Bvd6TgrVOkbMC7EyzgpmoxE atVfizU98gqqxDLIEHt4G2KQQpmauVNklugdulSBPgrwkTN0oZ TrYMpeSC8IzyHsiaB+E4AdmojYHEf88niLfR0as2qE= Subject: [martini] Fw: Meeting rescheduled: MARTINI WG Virtual Meeting III X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 00:45:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0DCE_01CA9B93.032C4090 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, My apologies - Bernard spotted that the start time for our III interim = meeting was incorrect on the WebEx invitation I forwarded - Alexa = quickly fixed this on a Friday afternoon... Spencer ----- Original Message -----=20 From: IETF Secretariat=20 To: spencer@wonderhamster.org=20 Sent: Friday, January 22, 2010 5:39 PM Subject: Meeting rescheduled: MARTINI WG Virtual Meeting Hello ,=20 IETF Secretariat changed the time for this online meeting.=20 Topic: MARTINI WG Virtual Meeting=20 Date: Tuesday, February 9, 2010=20 Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)=20 Meeting Number: 969 465 025=20 Meeting Password: martini=20 -------------------------------------------------------=20 To join the online meeting (Now from iPhones too!)=20 -------------------------------------------------------=20 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D11120979= 32&PW=3DNZjNiMTY2ODYx&RT=3DMiM0=20 2. Enter your name and email address.=20 3. Enter the meeting password: martini=20 4. Click "Join Now".=20 To view in other time zones or languages, please click the link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D11120979= 32&PW=3DNZjNiMTY2ODYx&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D131322887&tollFree=3D0=20 Access code:969 465 025=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 amorris@amsl.com=20 1-510-492-4081=20 To update this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D11120979= 32&ICS=3DMRS3&LD=3D1&RD=3D2&ST=3D1&SHA2=3DFKFrM/VXl6V1pDv1V4vEfINO/rCHPTw= ZP3yrb0IWfUc=3D&RT=3DMiM0=20 WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the = meeting by clicking this link:=20 https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://workgreen.webex.com/workgreen/systemdiagnosis.php=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, do = not join the session.=20 ------=_NextPart_000_0DCE_01CA9B93.032C4090 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,
 
My apologies - Bernard spotted = that the=20 start time for our III interim meeting was incorrect on the WebEx = invitation I=20 forwarded - Alexa quickly fixed this on a Friday = afternoon...
 
Spencer
 
----- Original Message -----=20
From: IETF = Secretariat=20
Sent: Friday, January 22, 2010 5:39 PM
Subject: Meeting rescheduled: MARTINI WG Virtual = Meeting

Hello , =

IETF=20 Secretariat changed the time for this online meeting.

Topic: = MARTINI WG=20 Virtual Meeting
Date: Tuesday, February 9, 2010
Time: 8:00 am, = Pacific=20 Standard Time (San Francisco, GMT-08:00)
Meeting Number: 969 465 025 =
Meeting Password: martini=20


------------------------------------------------------- =
To join=20 the online meeting (Now from iPhones too!)=20
-------------------------------------------------------
1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D13132288= 7&UID=3D1112097932&PW=3DNZjNiMTY2ODYx&RT=3DMiM0=20
2. Enter your name and email address.
3. Enter the meeting = password:=20 martini
4. Click "Join Now".

To view in other time zones or=20 languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=3D13132288= 7&UID=3D1112097932&PW=3DNZjNiMTY2ODYx&ORT=3DMiM0=20

-------------------------------------------------------
To = join the=20 audio conference only=20
-------------------------------------------------------
To = receive a=20 call back, provide your phone number when you join the meeting, or call = the=20 number below and enter the access code.
Call-in toll number = (US/Canada):=20 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?se= rviceType=3DMC&ED=3D131322887&tollFree=3D0=20

Access code:969 465 025=20

-------------------------------------------------------
For=20 assistance
------------------------------------------------------- =
1. Go=20 to https://workgreen.webex.com/workgreen/mc
2. On = the left=20 navigation bar, click "Support".

You can contact me at:
amorris@amsl.com
1-510-492-4081 =

To update this meeting to your calendar program (for example = Microsoft=20 Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=3D13132288= 7&UID=3D1112097932&ICS=3DMRS3&LD=3D1&RD=3D2&ST=3D1&am= p;SHA2=3DFKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=3D&RT=3DMiM0= =20


WebEx will automatically setup Meeting Manager for Windows = the first=20 time you join a meeting. To save time, you can setup prior to the = meeting by=20 clicking this link:
https://workgreen.webex.com/workgreen/meetingcenter/mcset= up.php=20


The playback of UCF (Universal Communications Format) rich = media=20 files requires appropriate players. To view this type of rich media = files in the=20 meeting, please check whether you have the players installed on your = computer by=20 going to https://workgreen.webex.com/workgreen/systemdiagnosis.php= =20

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com=20



IMPORTANT NOTICE: This WebEx service includes a feature = that=20 allows audio and any documents and other materials exchanged or viewed = during=20 the session to be recorded. By joining this session, you automatically = consent=20 to such recordings. If you do not consent to the recording, do not join = the=20 session.
------=_NextPart_000_0DCE_01CA9B93.032C4090-- From dean.willis@softarmor.com Fri Jan 22 21:58:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AEF3A6860 for ; Fri, 22 Jan 2010 21:58:50 -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_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ8+0OcAmLAU for ; Fri, 22 Jan 2010 21:58:49 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 027823A67D4 for ; Fri, 22 Jan 2010 21:58:48 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0N5weEh011989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 23:58:42 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B59DD3F.5030509@nostrum.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: Fri, 22 Jan 2010 23:58:35 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 05:58:50 -0000 On Jan 22, 2010, at 11:15 AM, Adam Roach wrote: > " > Now, if we stick with the "the SSP does not rewrite the URI" > approach that Keith and John are rather adamant about, the only > thing we can really do in terms of "these numbers go here, those > numbers go there" looks something like this: > I don't understand. Why is the INVITE showing up at ssp with a telephone number embedded in the user-part of a SIP URI in some abstract domain not associated with the target domain? That's not the use case that was put forward for MARTINI; the assumption is that requests are are either user@domain where the domain part is owned by the PBX, or are telephone numbers. And properly encoded telephone numbers are tel: URLs; they don't have domain-parts, so the domain- part doesn't have to be re-written on forwarding (but contact-routing ALWAYS rewrites it, as the AOR-target resulting from contact routing is always a SIP URI). > > > > I suspect most people can tell that's wrong by simple inspection. > What I'm willing to bet people are expecting is something more like > this: > > > > But that's most certainly not the "domain routing" model Dean is > talking about. In fact, it's pretty much the "contact routing" model > straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com > => sip:+15005550100@pan-am.com" (and a similar one for +15005550200). No, it's neither: it's table-driven retargeting. You're transforming a request for one domain into a request for another domain, based strictly on the "user part" of the original request. This is ignoring the domain-part of the registered AOR. So it's not contact routing; remember, contact-routing takes as its input an AOR. It looks this AOR up in a table populated by storing AORs (including user and domain parts) received in REGISTER requests, returns the Contact matching the AOR, and replaces the request URI with the Contact before proxying the request on. By matching only on the user-part of the AOR, you;re doings something that isn't quite contact routing. What happens when "+15005550100" is a valid user-part on both the pan- am.com and braniff.com domains? > > Okay, great. So the "contact routing" approach works fine for the > later cases. But what about the people who want to register entire > domains? That's the neat thing about the "contact routing" approach > -- if done correctly, it works just fine for those cases, too. Going > back to the first example; if we perform normal "contact routing" -- > URI rewriting and all -- and have the PBXes register their IP > addresses as the mapped contacts, everything works fine: > > > > This is great! Now we're using REGISTER to put an AOR to Contact > mapping in place (like it always has) instead of using it to install > rules to override normal RFC3263 handling. Best of all, we're not > saying "ignore DNS and use this alternate mechanism for turning > names into addresses" like we have to with the "domain routing" > approach. Nope. What happens when the PBX supports two domains, and there might be user-name overlaps between the domains? If both dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are contact-routed by the SSP into dwillis@10.1.2.3 , we have something of a mess. This requires sending the untransformed r-URI to the PBX. Also, what happens to security assumptions around the AOR-contact mapping as assumed in draft-ietf-sip-outbound? We end up with traffic for multiple users occurring over one flow, and that leads to the attack-model we panned the early connection-reuse drafts for allowing. -- Dean From bernard_aboba@hotmail.com Sat Jan 23 08:49:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BCF93A681E for ; Sat, 23 Jan 2010 08:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=-1.129, 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 b7XYUS7Bxvni for ; Sat, 23 Jan 2010 08:49:22 -0800 (PST) Received: from blu0-omc2-s5.blu0.hotmail.com (blu0-omc2-s5.blu0.hotmail.com [65.55.111.80]) by core3.amsl.com (Postfix) with ESMTP id 68FEC3A67E9 for ; Sat, 23 Jan 2010 08:49:22 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jan 2010 08:49:18 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sat, 23 Jan 2010 08:49:51 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTtkAHdOmS6arnRiSZ0H2IEvG4wAIldSbQ Content-Language: en-us X-OriginalArrivalTime: 23 Jan 2010 16:49:18.0637 (UTC) FILETIME=[01472DD0:01CA9C4C] Subject: [martini] MARTINI Virtual Interim II X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 16:49:23 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=martini@ietf.org;RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100123T164951Z DESCRIPTION:When: Tuesday\, January 26\, 2010 9:00 AM-11:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: WebEx Conference\n\nNote: The GMT offs et above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~* ~*~*~*~*\n\nMARTINI Virtual Interim II\nJanuary 26\, 2010\n9 AM – 11 AM Pacific Time\n\nConferencing Details: \n\nSlide Presentations: http://www .drizzle.com/~aboba/MARTINI/Jan-Interim-II/\nJabber room: martini at jabb er.ietf.org (Please join)\nDial in Audioconference and WebEx details: ht tp://www.ietf.org/mail-archive/web/martini/current/msg00232.html\nAgenda: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/agenda.txt\n\n \n DTEND:20100126T190000Z DTSTAMP:20100123T164951Z DTSTART:20100126T170000Z LAST-MODIFIED:20100123T164951Z LOCATION:WebEx Conference ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim II TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000802DE4317393CA01000000000000000 010000000235EF56AB5EE84489A838B7588B93354 X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Tuesday\, January 26\, 2010 9:00 AM-11:00 AM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: WebEx Conference

\n\n

Note: The GMT offset above d oes not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

MARTINI Virtual Interim II

\n\n

January 26\, 2010< /SPAN>

\n\n

9 AM – 11 AM Pacific Time

\n\n

Conferencing Details:

\n\n

Slide Presentations:  http://www.drizzle.com/~ aboba/MARTINI/Jan-Interim-II/< /A>

\n\n

Jabber room:  martini at jabber.ietf.org (P lease join)

\n\n

Dial in Audioconference and WebEx details:   < /FONT>http://www.ietf.org/mail-archive/web/martini/cu rrent/msg00232.html

\n\n

Agenda: \; http://www.dri zzle.com/~aboba/MARTINI/Jan-Interim-II/agenda.txt

\n\n

 \;

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Sat Jan 23 13:40:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38913A6806 for ; Sat, 23 Jan 2010 13:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BSaKKMPLb9l for ; Sat, 23 Jan 2010 13:40:06 -0800 (PST) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id C29813A67BE for ; Sat, 23 Jan 2010 13:40:02 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.71]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Jan 2010 13:39:58 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sat, 23 Jan 2010 13:40:32 -0800 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqTtgDNJhhnr6gOQwy26APUGVMGAgIvq9YA Content-Language: en-us X-OriginalArrivalTime: 23 Jan 2010 21:39:58.0546 (UTC) FILETIME=[9C461B20:01CA9C74] Subject: [martini] MARTINI Virtual Interim III X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 21:40:07 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN=martini@ietf.org;RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100123T214031Z DESCRIPTION:When: Tuesday\, February 09\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).\nWhere: WebEx\n\nNote: The GMT offset above d oes not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\n \nTopic: MARTINI WG Virtual Meeting \nDate: Tuesday\, February 9\, 2010 \n Time: 8:00 am\, Pacific Standard Time (San Francisco\, GMT-08:00) \nMeetin g Number: 969 465 025 \nMeeting Password: martini \n\n\n------------------ ------------------------------------- \nTo join the online meeting (Now fr om iPhones too!) \n------------------------------------------------------- \n1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1 112097932&PW=NZjNiMTY2ODYx&RT=MiM0 \n2. Enter your name and email address. \n3. Enter the meeting password: martini \n4. Click "Join Now". \n\nTo vi ew in other time zones or languages\, please click the link: \nhttps://wor kgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY2O DYx&ORT=MiM0 \n\n------------------------------------------------------- \ nTo join the audio conference only \n------------------------------------- ------------------ \nTo receive a call back\, provide your phone number wh en you join the meeting\, or call the number below and enter the access co de. \nCall-in toll number (US/Canada): 1-408-792-6300 1-408-792-6300 \nG lobal call-in numbers: https://workgreen.webex.com/workgreen/globalcallin. php?serviceType=MC&ED=131322887&tollFree=0 \n\nAccess code:969 465 025 \n\ n------------------------------------------------------- \nFor assistance \n------------------------------------------------------- \n1. Go to https ://workgreen.webex.com/workgreen/mc \n2. On the left navigation bar\, clic k "Support". \n\nYou can contact me at: \namorris at amsl.com \n 1-510-492-4081 1-510-492-4081 \n\nTo update this meeting to your calendar program (for example Microsoft Outlook)\, click this link: \nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887&UID= 1112097932&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=FKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3 yrb0IWfUc=&RT=MiM0 \n\n\nWebEx will automatically setup Meeting Manager fo r Windows the first time you join a meeting. To save time\, you can setup prior to the meeting by clicking this link: \nhttps://workgreen.webex.com/ workgreen/meetingcenter/mcsetup.php \n\n\nThe playback of UCF (Universal C ommunications Format) rich media files requires appropriate players. To vi ew this type of rich media files in the meeting\, please check whether you have the players installed on your computer by going to https://workgreen .webex.com/workgreen/systemdiagnosis.php \n\nSign up for a free trial of W ebEx \nhttp://www.webex.com/go/mcemfreetrial \n\nhttp://www.webex.com\n DTEND:20100209T180000Z DTSTAMP:20100123T214031Z DTSTART:20100209T160000Z LAST-MODIFIED:20100123T214031Z LOCATION:WebEx ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:0 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim III TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000A0F5A9F27293CA01000000000000000 0100000000CB00DB75F59EC438ED4D62BF5DED94B X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Tuesday\, February 09\, 2010 8:00 AM-10:00 AM (UTC-08:00) Pacifi c Time (US &\; Canada).

\n\n

Where: WebEx

\n\n

Note: The GMT offset above does not re flect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Topic: MARTINI WG Virtual Meeting< BR>\nDate: Tuesday\, February 9\, 2010
\nTime: 8:00 am\, Pacific Standa rd Time (San Francisco\, GMT-08:00)
\nMeeting Number: 969 465 025
\n Meeting Password: martini
\n
\n
\n------------------------------- ------------------------
\nTo join the online meeting (Now from iPhones too!)
\n-------------------------------------------------------
\n1 . Go to https://w orkgreen.webex.com/workgreen/j.php?ED=131322887&\;UID=1112097932&\;P W=NZjNiMTY2ODYx&\;RT=MiM0< FONT SIZE=2 FACE="Tahoma">
\n2. Enter your name and email address.
\ n3. Enter the meeting password: martini
\n4. Click "\;Join Now" \;.
\n
\nTo view in other time zones or languages\, please click the link:
\nhttp s://workgreen.webex.com/workgreen/j.php?ED=131322887&\;UID=1112097932&a mp\;PW=NZjNiMTY2ODYx&\;ORT=MiM0
\n
\n------------------------------ -------------------------
\nTo join the audio conference only
\n---- ---------------------------------------------------
\nTo receive a call back\, provide your phone number when you join the meeting\, or call the number below and enter the access code.
\nCall-in toll number (US/Canad a):  1-408-792-6300  1-408-792-6300
\nGlobal call-in numbers:< /SPAN> < SPAN LANG="en-us">< FONT COLOR="#0000FF" SIZE=2 FACE="Tahoma">https://workgreen.webex.com/work green/globalcallin.php?serviceType=MC&\;ED=131322887&\;tollFree=0
\ n
\nAccess code:969 465 025
\n
\n-------------------------------- -----------------------
\nFor assistance
\n------------------------- ------------------------------
\n1. Go to https://workgreen.webex.com/workgreen/mc
\ n2. On the left navigation bar\, click "\;Support"\;.
\n
\nY ou can contact me at:
\namorris at amsl.com
\n 1-510-492-4081  1-510-492-4081
\n
\nTo update this meeting to your calendar program (for example Microsoft Outloo k)\, click this link:
\nhttps://workgreen.webex.com/workgreen/j.php?ED=131322887&\ ;UID=1112097932&\;ICS=MRS3&\;LD=1&\;RD=2&\;ST=1&\;SHA2=FKFr M/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=&\;RT=MiM0
\n
\n
\nWebEx will automatically setup Meeting Manager for Windows the first time you j oin a meeting. To save time\, you can setup prior to the meeting by clicki ng this link:
\nhttps://workgreen.webex.com/workgreen/meetingc enter/mcsetup.php
\n
\n
\nThe playback of UCF (Universal Communicat ions Format) rich media files requires appropriate players. To view this t ype of rich media files in the meeting\, please check whether you have the players installed on your computer by going to https://workgreen.webex .com/workgreen/systemdiagnosis.php
\n
\nSign up for a free trial of We bEx
\nhttp://w ww.webex.com/go/mcemfreetrial< /A>
\n
\nhttp://www.webex.com< SPAN LANG="en-us">

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From dean.willis@softarmor.com Sat Jan 23 18:36:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D7628C0E6 for ; Sat, 23 Jan 2010 18:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_50=0.001, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKKqPI5LCZK7 for ; Sat, 23 Jan 2010 18:36:12 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 340913A680F for ; Sat, 23 Jan 2010 18:36:09 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0O2a68d019720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Jan 2010 20:36:08 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: Message-Id: <5EE84E20-E525-4A3F-BCC6-2A0AA9134998@softarmor.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: Sat, 23 Jan 2010 20:35:58 -0600 X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Fw: Meeting rescheduled: MARTINI WG Virtual Meeting III X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 02:36:13 -0000 So when is it? The note below says 8 AM PST, and the invitation Bernard just sent out says 9 AM PST. -- Dean On Jan 22, 2010, at 6:45 PM, Spencer Dawkins wrote: > Hi, > > My apologies - Bernard spotted that the start time for our III > interim meeting was incorrect on the WebEx invitation I forwarded - > Alexa quickly fixed this on a Friday afternoon... > > Spencer > > ----- Original Message ----- > From: IETF Secretariat > To: spencer@wonderhamster.org > Sent: Friday, January 22, 2010 5:39 PM > Subject: Meeting rescheduled: MARTINI WG Virtual Meeting > > Hello , > > IETF Secretariat changed the time for this online meeting. > > Topic: MARTINI WG Virtual Meeting > Date: Tuesday, February 9, 2010 > Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 969 465 025 > Meeting Password: martini > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY2ODYx&RT=MiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: martini > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&PW=NZjNiMTY2ODYx&ORT=MiM0 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=131322887&tollFree=0 > > Access code:969 465 025 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To update this meeting to your calendar program (for example > Microsoft Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=131322887&UID=1112097932&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=FKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP3yrb0IWfUc=&RT=MiM0 > > > WebEx will automatically setup Meeting Manager for Windows the first > time you join a meeting. To save time, you can setup prior to the > meeting by clicking this link: > https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media > files requires appropriate players. To view this type of rich media > files in the meeting, please check whether you have the players > installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed > during the session to be recorded. By joining this session, you > automatically consent to such recordings. If you do not consent to > the recording, do not join the session. > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernarda@microsoft.com Sun Jan 24 13:45:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FF23A6946 for ; Sun, 24 Jan 2010 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 05sefeLncGq9 for ; Sun, 24 Jan 2010 13:45:31 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 7BFFD3A6829 for ; Sun, 24 Jan 2010 13:45:31 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 24 Jan 2010 13:46:17 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.21; Sun, 24 Jan 2010 13:45:30 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.138]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sun, 24 Jan 2010 13:45:29 -0800 From: Bernard Aboba To: Dean Willis , Spencer Dawkins Thread-Topic: [martini] Fw: Meeting rescheduled: MARTINI WG Virtual Meeting III Thread-Index: AcqcnfW7KcHLBqzRRzWkTFhMGiX9gAAoFxiw Date: Sun, 24 Jan 2010 21:45:28 +0000 Message-ID: References: <5EE84E20-E525-4A3F-BCC6-2A0AA9134998@softarmor.com> In-Reply-To: <5EE84E20-E525-4A3F-BCC6-2A0AA9134998@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Fw: Meeting rescheduled: MARTINI WG Virtual Meeting III X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 21:45:32 -0000 Martini Virtual Interim II (January 26) begins at 9 AM PT.=20 Virtual Interim III (February 9) begins at 8 AM PT.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Saturday, January 23, 2010 6:36 PM To: Spencer Dawkins Cc: martini@ietf.org Subject: Re: [martini] Fw: Meeting rescheduled: MARTINI WG Virtual Meeting = III So when is it? The note below says 8 AM PST, and the invitation =20 Bernard just sent out says 9 AM PST. -- Dean On Jan 22, 2010, at 6:45 PM, Spencer Dawkins wrote: > Hi, > > My apologies - Bernard spotted that the start time for our III =20 > interim meeting was incorrect on the WebEx invitation I forwarded - =20 > Alexa quickly fixed this on a Friday afternoon... > > Spencer > > ----- Original Message ----- > From: IETF Secretariat > To: spencer@wonderhamster.org > Sent: Friday, January 22, 2010 5:39 PM > Subject: Meeting rescheduled: MARTINI WG Virtual Meeting > > Hello , > > IETF Secretariat changed the time for this online meeting. > > Topic: MARTINI WG Virtual Meeting > Date: Tuesday, February 9, 2010 > Time: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 969 465 025 > Meeting Password: martini > > > ------------------------------------------------------- > To join the online meeting (Now from iPhones too!) > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID= =3D1112097932&PW=3DNZjNiMTY2ODYx&RT=3DMiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: martini > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D11120979= 32&PW=3DNZjNiMTY2ODYx&ORT=3DMiM0 > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the =20 > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: https://workgreen.webex.com/workgreen/globalcalli= n.php?serviceType=3DMC&ED=3D131322887&tollFree=3D0 > > Access code:969 465 025 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > amorris@amsl.com > 1-510-492-4081 > > To update this meeting to your calendar program (for example =20 > Microsoft Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=3D131322887&UID=3D11120979= 32&ICS=3DMRS3&LD=3D1&RD=3D2&ST=3D1&SHA2=3DFKFrM/VXl6V1pDv1V4vEfINO/rCHPTwZP= 3yrb0IWfUc=3D&RT=3DMiM0 > > > WebEx will automatically setup Meeting Manager for Windows the first =20 > time you join a meeting. To save time, you can setup prior to the =20 > meeting by clicking this link: > https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php > > > The playback of UCF (Universal Communications Format) rich media =20 > files requires appropriate players. To view this type of rich media =20 > files in the meeting, please check whether you have the players =20 > installed on your computer by going to https://workgreen.webex.com/workgr= een/systemdiagnosis.php > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows =20 > audio and any documents and other materials exchanged or viewed =20 > during the session to be recorded. By joining this session, you =20 > automatically consent to such recordings. If you do not consent to =20 > the recording, do not join the session. > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Sun Jan 24 21:03:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3303A6358 for ; Sun, 24 Jan 2010 21:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGAY+kzlZgkD for ; Sun, 24 Jan 2010 21:03:16 -0800 (PST) Received: from blu0-omc2-s3.blu0.hotmail.com (blu0-omc2-s3.blu0.hotmail.com [65.55.111.78]) by core3.amsl.com (Postfix) with ESMTP id AD26E3A6893 for ; Sun, 24 Jan 2010 21:03:16 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jan 2010 21:03:21 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sun, 24 Jan 2010 21:03:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01CA9D38.BDA99F20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqcTCPXxxHcU5DwRL+/nW45gM76qQBLnWiA Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2010 05:03:21.0970 (UTC) FILETIME=[B7903520:01CA9D7B] Subject: [martini] MARTINI Virtual Interim II Agenda: January 26, 2010 - Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 05:03:20 -0000 ------=_NextPart_000_0070_01CA9D38.BDA99F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim II January 26, 2010 9 AM - 11 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00232.html Agenda 9 AM - 9:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements (20 minutes) 9:10 AM - 9:30 AM PT MARTINI Requirements, John Elwell (20 minutes) Invited Talks (30 minutes) 9:30 AM - 9:40 AM PT MARTINI Issues, Dean Willis (10 minutes) 9:40 AM - 9:50 AM PT Talk TBD (10 minutes) 9:50 AM - 10:00 AM PT Service Provider Perspective, TBD (10 minutes) Solution Updates (30 minutes) 10:00 AM - 10:15 AM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (15 minutes) http://tools.ietf.org/html/draft-roach-martini-up 10:15 - 10:30 AM PT SIP Implicit Registrations, Presenter: Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-shaken-implicit-registration s http://tools.ietf.org/html/draft-kaplan-martini-stirred-domain-registration Wrap-up (30 minutes) 10:30 AM - 10:40 AM PT Discussion: Participants (10 minutes) 10:40 AM - 10:55 AM PT Hums: WG Chairs (15 minutes) 10:55 AM - 11:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0070_01CA9D38.BDA99F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim = II

January 26, = 2010

9 AM – 11 AM = Pacific Time

 

Conferencing Details: =

 

Slide = Presentations:  http://www= .drizzle.com/~aboba/MARTINI/Jan-Interim-II/

Jabber room:  = martini at jabber.ietf.org (Please join)

Dial in Audioconference = and WebEx details:   http://www.ietf.org/mail-archive/web/martini/current/msg00232.html=

 

Agenda

 

9 AM - 9:10 AM = PT:  Preliminaries

     Conference issues/debugging

     Agenda bash

 

Requirements (20 = minutes)

 

9:10 AM – 9:30 = AM  PT MARTINI Requirements, John Elwell (20 minutes)

 

Invited Talks (30 = minutes)

 

9:30 AM – 9:40 AM = PT  MARTINI Issues, Dean Willis (10 minutes)

 

9:40 AM – 9:50 AM PT  Talk TBD (10 = minutes)

 

9:50 AM – 10:00 = AM PT  Service Provider Perspective, TBD (10 minutes)

 

Solution Updates (30 = minutes)

 

10:00 AM – 10:15 =  AM PT Multiple AOR Registrations in SIP, Presenter: Adam Roach (15 = minutes)

http://tools.i= etf.org/html/draft-roach-martini-up

 

10:15 – 10:30 AM PT SIP Implicit = Registrations, Presenter:  Hadriel Kaplan (15 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-shaken-impl= icit-registrations

http://tools.ietf.org/html/draft-kaplan-martini-stirred-domai= n-registration

 

Wrap-up (30 = minutes)

 

10:30 AM - 10:40 AM = PT  Discussion:  Participants (10 minutes)

10:40 AM - 10:55 AM = PT  Hums:  WG Chairs (15 minutes)

10:55 AM – 11:00 = AM PT   Next Steps:  WG Chairs & ADs (5 minutes)

 

 

 

------=_NextPart_000_0070_01CA9D38.BDA99F20-- From bernard_aboba@hotmail.com Sun Jan 24 23:55:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E103A6767 for ; Sun, 24 Jan 2010 23:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKP7AadoZ0h6 for ; Sun, 24 Jan 2010 23:55:44 -0800 (PST) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id B976C3A6915 for ; Sun, 24 Jan 2010 23:55:44 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jan 2010 23:55:49 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sun, 24 Jan 2010 23:56:24 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CA9D50.D606E100" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqdk+PEGKS6TcKhRomycftSO2EXAg== Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2010 07:55:49.0987 (UTC) FILETIME=[CF764B30:01CA9D93] Subject: [martini] Final request: agenda items and slides for Virtual Interim II: January 26, 2010 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 07:55:48 -0000 ------=_NextPart_000_0001_01CA9D50.D606E100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim II will take place on Tuesday, January 26, 2010 from 9 AM - 11 AM Pacific Time. That's a mere 33 hours away! If you're not on the agenda and want to be, or if you're on the agenda and don't want to be (or want to adjust your time allocation), please inform Spencer and myself of your needs ASAP. If you're on the agenda, please send your slides to Spencer and myself no later than end of business on Monday, so we can make sure the presentations are uploaded in time. ------=_NextPart_000_0001_01CA9D50.D606E100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim II will take place on = Tuesday, January 26, 2010 from 9 AM – 11 AM Pacific Time.   That’s = a mere 33 hours away!

 

If you’re not on the agenda and want to be, = or if you’re on the agenda and don’t want to be (or want to adjust your time allocation), please inform Spencer and myself of your needs ASAP. =

 

If you’re on the agenda, please send your = slides to Spencer and myself no later than end of business on Monday, so we can = make sure the presentations are uploaded in time.

------=_NextPart_000_0001_01CA9D50.D606E100-- From john.elwell@siemens-enterprise.com Mon Jan 25 01:25:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69523A68A3 for ; Mon, 25 Jan 2010 01:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMPHgr+-Eerb for ; Mon, 25 Jan 2010 01:25:09 -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 40D7B3A683D for ; Mon, 25 Jan 2010 01:25:08 -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-650591; Mon, 25 Jan 2010 10:25:13 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 871EA1EB82AB; Mon, 25 Jan 2010 10:25:13 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 25 Jan 2010 10:25:13 +0100 From: "Elwell, John" To: Adam Roach , Dean Willis Date: Mon, 25 Jan 2010 10:25:12 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqbhpFBgTEqzUacQayN346yCa5X0wCGF51g Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> In-Reply-To: <4B59DD3F.5030509@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 09:25:11 -0000 Adam, Thanks for going to the trouble of explaining things in this clear way. See= below. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 22 January 2010 17:16 > To: Dean Willis > Cc: Elwell, John; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 > "On 1/22/10 1:24 AM, Dean Willis wrote:=20 >=20 > Consider for example the debate we're currently having=20 > about whether the SSP does "contact routing" and replaces the=20 > r-URI with a registered contact, or does "domain routing" and=20 > just pushes the registered route onto the route stack=20 > (really, it MUST do the latter, but REGISTER implies the=20 > former, which makes it something of a hack). > =09 >=20 >=20 > I'm not sure it must do the latter. I think there are some=20 > people here whose use cases will work if you do it that way,=20 > but I think a careful examination of everyone's position will=20 > show that it simply won't work for others'. >=20 > On the other hand, the "contact routing" approach, as far as=20 > I can tell, will work for all the use cases described so far,=20 > as long as we have the ability to define a mapping from AOR=20 > to contact URI in some sensible fashion. The martini-up draft=20 > gives an existence proof of such a mechanism -- and the=20 > mechanism is hardly NOTIFY-specific. It could be used just as=20 > sensibly with REGISTER. >=20 > So, let's take a quick look at the "contact routing" approach=20 > versus the "domain routing" approach. I hope you'll excuse=20 > that I'm stepping slightly outside IETF norms to convey these=20 > concepts clearly: to save the confusion among "example.com,"=20 > "example.org," and "example.net," I'm going to use dead=20 > companies in my example; I'm also going to use inline images=20 > for my diagrams. >=20 > Ignoring how the information gets there in the first place,=20 > the "domain routing" approach looks sensible at first blush=20 > for this kind of application. Here is an SSP and two of its=20 > customers. Through some non-DNS mechanism, the SSP knows to=20 > route the domain "pan-am.com" to the Pan Am PBX, and to route=20 > the domain "braniff.com" to the Braniff PBX: >=20 >=20 >=20 > Great. Aside from the somewhat nonstandard determination of=20 > the next-hop server at the SSP, this is pretty normal handling. >=20 > That said, MARTINI has a special relationship with phone=20 > numbers. They're in our charter: " The solution will support=20 > AoRs with E.164 > addresses at a minimum, although support for other classes of=20 > AoRs may be included." So, let's explore what that ends up meaning. >=20 > As long as we expect some external party (not the SSP) to=20 > determine what domain each E.164 number belongs to, then=20 > everything works the same as my previous example: >=20 >=20 >=20 > And, if that's good enough, then great. But I'm willing to=20 > bet that at least one person working in this space looks at=20 > that diagram and says, "No! That's not what I meant! I want=20 > the SSP to handle the number mapping." >=20 > Now, if we stick with the "the SSP does not rewrite the URI"=20 > approach that Keith and John are rather adamant about, the=20 > only thing we can really do in terms of "these numbers go=20 > here, those numbers go there" looks something like this: [JRE] Although I may not have made myself clear, what I really am adamant a= bout is preserving the identity of the target user in the Request-URI. So i= f the domain part is changed, but the user-info part is retained, that woul= d be satisfactory. >=20 >=20 >=20 >=20 > I suspect most people can tell that's wrong by simple=20 > inspection. What I'm willing to bet people are expecting is=20 > something more like this: >=20 >=20 >=20 > But that's most certainly not the "domain routing" model Dean=20 > is talking about. In fact, it's pretty much the "contact=20 > routing" model straight up, with an AOR to Contact mapping of=20 > "sip:+15005550100@centricvoice.com =3D>=20 > sip:+15005550100@pan-am.com" (and a similar one for +15005550200). >=20 > Okay, great. So the "contact routing" approach works fine for=20 > the later cases. But what about the people who want to=20 > register entire domains? That's the neat thing about the=20 > "contact routing" approach -- if done correctly, it works=20 > just fine for those cases, too. Going back to the first=20 > example; if we perform normal "contact routing" -- URI=20 > rewriting and all -- and have the PBXes register their IP=20 > addresses as the mapped contacts, everything works fine: >=20 >=20 >=20 > This is great! Now we're using REGISTER to put an AOR to=20 > Contact mapping in place (like it always has) instead of=20 > using it to install rules to override normal RFC3263=20 > handling. Best of all, we're not saying "ignore DNS and use=20 > this alternate mechanism for turning names into addresses"=20 > like we have to with the "domain routing" approach. [JRE] This would seem reasonable. The point is, if the PBX registers as its= contact address pbx123@10.15.2.4, then inbound INVITE requests would not c= ontain that same value in the Request-URI, but would contain something like= dsmith@10.15.2.4. The identity of the target is retained. So I think we ar= e in agreement. John >=20 > So, Dean: can you explain what breaks if we use "contact=20 > routing" for all the use cases described so far? >=20 > /a >=20 > = From BLINDSAY@nortel.com Mon Jan 25 06:38:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7F13A6876 for ; Mon, 25 Jan 2010 06:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, 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 dbPQi832ZC0v for ; Mon, 25 Jan 2010 06:38:24 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA5BC3A6838 for ; Mon, 25 Jan 2010 06:38:23 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0PEbqO11529; Mon, 25 Jan 2010 14:37:53 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA9DCB.F9840206" Date: Mon, 25 Jan 2010 09:37:44 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C37188E@zcarhxm1.corp.nortel.com> In-Reply-To: <4B5A34FF.6050301@nostrum.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: Acqbut/5HNtI+DGoTaOEf6XllaCixQAEe54A References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C370FBE@zcarhxm1.corp.nortel.com> <4B5A34FF.6050301@nostrum.com> From: "Brian Lindsay" To: "Adam Roach" Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:38:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9DCB.F9840206 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA9DCB.F9840206" ------_=_NextPart_002_01CA9DCB.F9840206 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, =20 Regarding the 2nd mechanism - I don't think there's really anything new here. Performing such a re-targetting operation is probably typical for transit / indirect peering functions and this isn't specific to MARTINI. There's examples in the SPEERMINT VoIP SIP Peering Use Cases draft of this kind of operation for the indirect peering use cases. =20 Regards Brian ________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Friday, January 22, 2010 6:30 PM To: Lindsay, Brian (CAR:AR00) Cc: Dean Willis; Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Requirements - rev1 Brian: Yes, you could. But with that approach, you're needing to define two different mechanisms: * One that informs the "domain routing function" of the SSP where to route the domain pan-am.com, and =09 =09 * Another that informs the "look-up function" of the SSP how to convert "sip:+15005550100@centricvoice.com" to "sip:+15005550100@pan-am.com" =20 While we certainly could go down the path of defining yet more mechanisms, I would suggest that we don't. /a On 1/22/10 1:31 PM, Brian Lindsay wrote:=20 Hi Adam, =20 Regarding the case below, you could use a "domain routing" approach for this as well. =20 For example, the SSP could perform an intermediate step (e.g. using a local "Look-Up Function" to borrow from SPEERMINT terminology) that effectively provides the mapping from the E.164 number to the pbx domain and does the conversion from sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com . After that the routing mechanism kicks in. =20 ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Friday, January 22, 2010 12:16 PM To: Dean Willis Cc: Hadriel Kaplan; martini@ietf.org Subject: Re: [martini] Requirements - rev1 =09 =09 [... text deleted ....]=20 I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this: =09 =20 =09 But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of " sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com" (and = a similar one for +15005550200). =09 =09 ------_=_NextPart_002_01CA9DCB.F9840206 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Adam,
 
   Regarding the 2nd mechanism - I don't think = there's=20 really anything new here. Performing such a re-targetting operation = is=20 probably typical for transit / indirect peering functions and this isn't = specific to MARTINI. There's examples in the SPEERMINT VoIP SIP=20 Peering Use Cases draft of this kind of operation for the indirect = peering use=20 cases.
 
  =20 Regards
     =20 Brian

From: Adam Roach = [mailto:adam@nostrum.com]=20
Sent: Friday, January 22, 2010 6:30 PM
To: Lindsay, = Brian=20 (CAR:AR00)
Cc: Dean Willis; Hadriel Kaplan;=20 martini@ietf.org
Subject: Re: [martini] Requirements -=20 rev1

Brian:

Yes, you could. But with that approach, you're = needing=20 to define two different mechanisms:
  • One that informs the "domain routing function" of the SSP where to = route=20 the domain pan-am.com, and

  • Another that informs the "look-up function" of the SSP how to = convert "sip:+15005550100@centricvoice= .com"=20 to "sip:+15005550100@pan-am.com" =

While we certainly could go down the path of defining yet = more=20 mechanisms, I would suggest that we don't.

/a


On = 1/22/10 1:31=20 PM, Brian Lindsay wrote:=20
Hi=20 Adam,
 
   Regarding the case below, you = could use=20 a "domain routing" approach for this as well.
 
   For example, the SSP could perform = an=20 intermediate step (e.g. using a local "Look-Up Function" to = borrow=20 from SPEERMINT terminology) that effectively provides the mapping from = the=20 E.164 number to the pbx domain and does the conversion from sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com. After that the routing mechanism kicks=20 in.
 

From: martini-bounces@ietf.org = [mailto:martini-bounces@ietf.org<= /A>]=20 On Behalf Of Adam Roach
Sent: Friday, January 22, = 2010 12:16=20 PM
To: Dean Willis
Cc: Hadriel Kaplan; martini@ietf.org
Subject: = Re:=20 [martini] Requirements - rev1

[... text=20 deleted ....] 
I suspect most people can tell = that's=20 wrong by simple inspection. What I'm willing to bet people are = expecting is=20 something more like this:

3D""=20

But that's most certainly = not the=20 "domain routing" model Dean is talking about. In fact, it's pretty = much the=20 "contact routing" model straight up, with an AOR to Contact mapping of = "sip:+15005550100@centricvoice.com =3D> = sip:+15005550100@pan-am.com" (and a = similar one for=20 +15005550200).


------_=_NextPart_002_01CA9DCB.F9840206-- ------_=_NextPart_001_01CA9DCB.F9840206 Content-Type: image/png; name="ATT2291539.png" Content-Transfer-Encoding: base64 Content-ID: <328473801@23012010-2C00> Content-Description: ATT2291539.png Content-Location: ATT2291539.png iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAAeAGt k81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UURBC8ePDm RS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn1tSLly6ro3tQ MIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzTd3x6GoKNRsUk3yUn 3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZeRS02x3mj4mcJwzH5dzY e/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVSZqpebSEp0yljx4EjO0HwLQBG 6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw5B39ncO6SJcGPN4ByveAPMcHHOd+ AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmI a81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXO et9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEIDUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+Rd pzrObbdZb/jqKv9IK6HmbONUQk1q8xp+A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAg AElEQVR4AexdB5wURfr9ejawCywZyVEUwYjxzKCY9UynnoqZv2c8w3lGTtd8euehYjoT5oQ5B5IJ z0BUEMmKBIElbWDDbNf/ve6pnd5xNqeZ3e/b39vK1VWverrfVNV0i6gpA8qAMqAMKAPKgDKgDCgD yoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPK gDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qA MqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMJBkDTpK1V5urDCQM Axk9XReN0c9QwoxIvTTEFK4MheqlJq1EGVAGWhQDqS2qt9pZZaB+GXC2rFA9Vb+UNm1tmb2MDmjT DoEeXRlIWgb0m1jSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOV AWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIky EtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFlIFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVA BVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaUAWVAGUhaBlRQJe3QacOVAWVAGVAGlAFl IFEYUEGVKCOh7VAGlAFlQBlQBpSBpGVABVXSDp02XBlQBpQBZUAZUAYShQEVVIkyEtoOZUAZUAaU AWVAGUhaBlRQJe3QacOVgdozsOo3I1u2mNpX0AQli4uTq71NQJEeUhlQBpqQARVUTUi+HloZqC4D 515qJLNXFIN2N3LlGCPhsC8yCiCO2vQxctZF5UXHex8b+cNh0bhHxhvZ53Ajh58ksv2+IsefaeS3 tdH0YHu22SN6PB6723ZGjjjFyK8r4+cPlq1vf856I312EjGm8Y9d333R+pQBZaB5MqCCqnmOq/aq mTEwfbbIS4+LbFnhyKalvv+DSSJ3j/M7OvsHkTatRd78QGT9hqjomDFHZFcIEdrET428/q7IOy+I zP7MkblfiqxYJfLUi3568P+adRROIivn+sfkced8jnI4zuPPBnM2jv+7WSK77CjiOE7jHFCPogwo A8pADRlQQVVDwjS7MtDYDOTmGVmwOCqM0tMd2X0XR0ZhlmnSp35rKJyOOFhkxyEiL74ebSGF2G47 ++Gb7xY5DHk6d/JFSWamI//8h8ghw6P5rW8Gym09QKRjh6iA6dbVkT69RHr39HOtw6zReX81wtmy w04ysmhJVMi99IaRnQ/w08bcHo1/7R0jux1kZKvBRs7EbFp+gZ92x1gDoWZk1AVGHsYsWlGRkatu NLLDfkZOOc/IJ1Oj/bBtVFcZUAaUgURiQAVVIo2GtkUZiMPAzO9FunQSiJmouGG2zAyR9FZ+AQqg YZiJOvd0kfGYgbI2kzNUEUHVq4fIvzCjRaHC2arCQiMHHeBgBqt8vSxLIcaZLe5bIlauNpgNM7Jx k8ifT/BrPxbH6t9X5KMJvpC74G9+/CtvGrn132jHA5j9elDkoSdFvptl5IuvjdwxVuSZhxCeLPLj ApHHnvHLfDBR5L5HRXbeAcuQR4lcfLXI4mUi//2PSLetRB58Iioo/RL6XxlQBpQBZUAZUAaaBQMZ PV1s6Wl4G/uwa4457ffHuux611xxgx+/8wGu+fRL12zOdU3nQa75erprlq9wTbv+riku9vNs2uya cY+5Zu/DXJPZyzW9d3DN86/+vl726ISzXMP+BcEys77387/7kWtOPjdadsYc1/TdyTXhsGv67Ii2 TIumPfSka5Ysc81Rf3bNxE+j8dfd6poL/uaakhLXtB/gmg8n+Wk//+rXkZfvh39a6LeDdTS0sb/N 4uTUTigDykCjM6AzVI1OuR5QGagZA8F9ULZkaamRDyeJnHGKSF6+kYVL/NmdrLaOnHSsP0vFclwC TEvzZ6DaZTlyyWhHpn3oyPyvRfb7A2erbI3lXc54vYu9VesW+vjxK8wUdRV5/lU/3z/vE/l0msjA XY2HP57mzyR9+Q1mzdJF9kfd1i48x5ENmNla+ovIQfvbWJHNuSKcNZuPY3TtjOXIg/x2Poi9Yqdj ObNNaz/cCrNwHdqLDOj3+5m0aG3qUwaUAWWgaRlQQdW0/OvRlYEqGeDyG5fzgvbMyyLtshC/oyNc EuTSW/t2vuDgst+EtyB4sOncLvfxl36fTI1OvvTF8uEZJ/vLhsF66efy3uo1Invu6osaCpv+fR3Z dy+R1FQ/N4/5Ptow/38+fsCxpuCYCxeL9OgW3TzOXxB+Ns3ILOTv1iUaX1LiC8KzTxXxliUD/ZuF je8Ub9beeE+X+ywX6ioDykDiMqCCKnHHRlumDGDPkpEly6KCirNRDz1p5HbsLXryfp8gzibZX/Ix Zo9hDmZz8Gu857CROyJUKLUmfebn539udH/0GcwE/SkaZ32sb9BAEc52BW31byLbIB7LbhBvmHH6 mbNRjqxeK7LXoeJtnGf8GoQ3bDTCWbQLrxLZlCvSGr9AXInyjKc9+bzICMxW9e7pC0L+gs9a2zYi 87C/ysXq24pV3KSuG9ItN+oqA8pA4jIQ+b6ZuA3UlikDLZkBzt7QBu/J/8ab/TlwH5G3IUiGDvYF DwXQsIAgYU7OUl05JjpDdev1gl/V4bEK7+MXdpgpKiwSGXmgyI1/Z+7yxqXC2PqYY9lywa/y/Fmm G67kr/RE/v2AkZz1Inf8w58t22agkbEPY6lxP38J8KhDRI45zMHynpH/POQ/+4p5uIw3fpx/XM5e Xf3XaBv++n8ix54hMu0bEYqr3lgWtDNt0VzqUwaUAWUgsRgo/xU0sdqmrVEGEpoBbmDm85mSxfhk dD5+oVPH3/9isDZ9WJuDpUHMOg0e5M9UBev4ZYXxhFAoFOWHM1Y8PvdD9egWjQ+Ws37OzK1d58+U Neazp/gA08KVgUbbBqmrDCgDykAVDFR+VauisCYrAy2ZgWQTVC15rKrbdxVU1WVK8ykDykAsA6HY CA0rA8qAMqAMKAPKgDKgDNSMARVUNeNLcysDyoAyoAwoA8qAMvA7BlRQ/Y4SjVAGlAFlQBlQBpQB ZaBmDKigqhlfmlsZSEgGFi428v4n/iMJYhs4d77/8M3Y+LqG+a6+ad/GP2Zd69byyoAyoAwkGwMq qJJtxLS9ykAcBp59RfCuvDgJiOrbW2Ti6/HT6hL7wqN4+OewutSgZZUBZUAZaD4MqKBqPmOpPUky Bl56wwhneQbtbmTM7dGZni+/MTLyeD/+kmuMhMN+2s13GzwQ08jJ5/ozTufjWVB8yOYdY4089qzI q2+JfP4/P/z4s0ZGXcCHYhq5H8KHTx+nLVhk5IhT8DyroUZOO9/Isl+MjHvMyD/uiB7/5+VGDv2T ET5mYfFSI388Hc+uGmzw8E4js3/w8/FFx3wwaGqq4+W7coyRvjsZ2f8oI29/6Odh2+59xMiw4T6e fzV6DL81/n8eJ155vrz5mpv9vvIVN+wLjfWOONbIC6/5x+Mxv5lhhHxsvZuRsy823kNB/dr1vzKg DCgDyoAyoAwkNAN8bEJt7eU3XDN0H9dMn+2az//nmo4DXfPtTNcsWOSabfdwzStvuoYvBd7tINc8 +IR/nN0Pds2eh7jmy29c8+wr/guD+QLkX1e6ptPW/guJt2xxzX5HumaH/Vxz9zjXrPrNNSw39QvX rF7jmn47u+aZl1yzaIlrDjnBNXxB8SPjXTPy+Ghf+MLi2+7xX6rMetiWdTmuuTrbNfsf5ee7817X XHqt7z/lPNeMvsw1S392za3/Rvv39OP/9YBrjj7V79d7H/svQGZbY62i8nzxM4/Bdn88xTVZ/Vyz bLnPEbm/6O/+S6D3OtTv/9Mv+i+IZhrz1cZYNqFPOm2cMqAMKAPKgDLQ3BioraAKh13TZ0dfANmb /kNPumbJMtece6lrXoLYsjbmdtdcfj0eIAqh1KaPa+b95KexDh4/Z70vZLpt58eXlPjC5cNJfpjl 2vZ1zYaNrrnkGtf89bpo3Z9Oc83bH7pm4qeuGbK3H09RNGh31+Tlu2b8C6658Kpofgq+rQb7YYqg J5/3hVr/XVzD9tAovCi2cvN8wciwNR6D4jFoFHrxylNEUVgWFUXzU6h9MtU1FKPDhrvGdf20k86J 9qu42DWte7tmbeC4weNV5VdB1dw+pdofZUAZUAaUgYRnoLaCikJm692igsDe5CmoKAYoMAYM89Fl G9f88z5/lme7P0TFxXzMXlGU0d54zzWH/sn3fz/PF0S2TooglqP46LuTa6Z9E63D5ln2i2s6YIaM dv6Vrnn0aT8/BdCMOdH8kz9zzS4H+mGKHaZdBrF31Y3RPLbO/zzkmnb9o/1gfygIFy4un7ei8jfc 5hrCGtvfc3vXzJ3vz6pRaFrjTN//vvPDs773Z+FsWk1dFVQJ/7HTBioDCcuAvssvYYdGG9ZcGViI 16/06Oa/E499/G2tkZ8WimzcLDKwv8j0SdGeb87Dq1rwwuGnXhTZfZdoPN+3Z18ozHfh2Xfv8d1/ wRcl27RNqHsNXuXSq2e0Du51OvwgvoZG8CJjke9mGfl2hsiDd+GFxsjPlx933yqa/9V3RM4/S2T9 BiOr1uC9fIP9FyIfOjyaZ/psIx3xahke97LzRcb8zU8Lo/7CQr72pvzLGfgqmnjlZ6D8kSOj9U75 HO8u3NZ/f+HM7438Be2gbdps5JdfRXYa6od5XMuLH6P/lQFlQBloHAZ0U3rj8KxHUQbKGGgPgbRm rciGjQZCxsiFV0EY5Ipk4UXAfH9dwRb/3XhvfyhyyAkUXiIzIRSsaGJFFA5WOM2ZJzJkG7965gsK Cq/cTiKt0gG8kJjCjfbMS0beeNc/Dt+3N7CfyOV4gfJNV/sbzdPSRIh5P/n5lywzMhmi5uw/+8ce CjGVnu5I+yzUucjfKP7rSiPnXirSsQNeatwWguwX1uWLtUuvEW9zPGv7erqRRUv8rUoVlm8tMh9t xQyTlJQYuQcvVv7bxX5b2Pdh6BNtNjbb812CmZm+UKMQC/Lk59L/yoAyoAwoA8qAMpCwDNR2yY/7 i/Y53DW9sIS16wjX/OMOf7mK+5AOO8nfp7Tj/v5G8cVL/TTmn/J5dJmLG8q51EfjMh2X83751TUj /uiaDyZG87Ec9x3Rbr7bX1LcY6RrjjzF32juJeDfiWe75sBjouUYf/2trsns5ZqDjnXN9vu6xu7L +veDrvkLjknjEiKXJZnOzeEfTfbjf/jRNb138DfHs23cYM79XbTBe7nmxdcrL89lUW60514pLumx LTQuT3Lpz9q9j2BD/OXR8AFHu+atD6Jhm6+6ri75JezHTRumDCQ8A+Xn3xO+udpAZSBxGODNd8uK 2n+EfllhpHcPEc4QWcONH7M3IikpXP6Lxtv0ityNm4x0aF91/pz1xpt5apdVdV4ea8UqI3n5IoMG sE3xyxQVGcnZINKze/l0PvZgIfrSs7tI507l04L9qKh8Xr7xlh0HYPasbZuKywfrqqtfX45cVwa1 vDLQchlonKtUy+VXe96MGairoGrG1CRt11RQJe3QacOVgSZnQPdQNfkQaAOUAWVAGVAGlAFlINkZ UEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQBZUAZUAaSnQEVVMk+gtp+ZUAZUAaUAWVA GWhyBlRQNfkQaAOUAWVAGVAGlAFlINkZUEGV7COo7VcGlAFlQBlQBpSBJmdABVWTD4E2QBlQBpQB ZUAZUAaSnQG8GEJNGVAGlIHkYYAP/FyxSmQlwFf28MGj+UBeAZAnZtNmpxjvQAyzR5mtJJSRISmZ GSYVr94J8fU7fA3PVl1F+vUW6QsE36uYPCxoSxOcgXjPeIwXl+DdaFbN8993Vb5L8eLK56hBSAVV DcjSrMqAMtDwDKzN8Z+wvggvTl60TErxkuYteAFyeOVqCa3NkVZ4kbOTmSk5rdJkBR4sv8l1ZXO4 1GwqKpYNeAHzBscxecBmMU6KcaSVuNKKbmoo1Co13W2TliIZGa1CA1zXDCwslh7FRdJ6qy5mS5/e Dl7hLHgToZoyUGMGKJasYIr128psug2r27gMBMWT9dON569Vy1RQ1Yo2LaQMKAN1YYAvhV60VOSH H/lyZcf94UdT8OMCJ7xsucmEAApntpZfjDjzNm5yZ0qpWWlCZoVx3RXFhQUrZGPHjXm1OHhxhWWW Z65wt+q38rdQP1cMXk+tpgxUm4GgeOIWGoata/2sLJiPYbXGZyAonlwc3oatny7HycbXuIUsrKYM KAO1YEBfPVM90tasMzJnri+eZsyR/JmzJbx0ubRpnSE5aekyJzfXmV5YXDrfuGZBeMuWBZLbLqd6 NWsuZaBJGbAiiS5FlAXexOn56do0mxdRXhxdtcZhgAKJZoWSFVCckabfuvTbNJsXUdU3naGqPlea UxlQBqpgYBnmlWb9IDJjjhP+6luTP2eepJUUS2lmhizES5C/yd9ippe67pyS0Lof8hf2xK4nNWUg aRmwIolCiuLJYiP8TFNLfAYonLjMT1FF0CiqaFaI+aFq/FdBVQ2SNIsyoAyUZwD7j2TBYvHE0/RZ TvFX30nB3PkmMxSSfGz8/j53s/tZcamZXlxYPEPWt16+oXxxDSkDyc6AFUxWTPFeSqQBjsHmPrXE Z8CBoZX4qYqUAHZM2XCKK4ZrNJAqqEidmjKgDFTIQHGxkXk/+eLpu1lS+L/vpAhiqnVGK8lJTZVZ Gza5nxnjTi+SLTNkZTvdg1Qhk5rQjBjgzTa4xMd7KX4/6t2cm1E3W0RXMtBLK6YooCzs8l+1SVBB VW2qNKMy8HsGcvOMZLW1n8XfpydbTM56f7/TbOx5+naWkzd9lnF/XSmt27aRFejldxs2mS9KxZ0R Ltk4M/fnrnhogZoy0GIZsKKKS32cmeJMB2/OasnFgB0zCim7j8ou+9WoJyqoakSXZlYGogx062qe 7LWDc/rO25vC449yso4YaUJDtk0OccVnOf24QGQ+MG+BUzJjjimYMVvSC4sk1C5L5hcVOl/l55V+ W5rizipZ+fPcfNmmKNpz9SkDLZ6BWDFFQcUZqswWz0zyEcAxo4DiMl9QUNVYVCXH1T/5Bkhb3FIY 6LmydavSrQ7Kap9ynHHljxkZpvUxhzkhiKvMwYNEtu6PjRWpTfMxKykxguc3ybLlIj8DeERB8awf nIKfFpk0PBAzPauN87Mj5ocNm813Jmy+d0Kh+11TclTx6laYn1JTBpSBShiws1IUUZzhaB1BW7hf 6x4qsJAE5m+hkr3QVD6JhT+SIQoBPmWF+6rsRnV4q7amudJX3S7NoQwkJQPpPYqGpDipR3Xo6BwV LpHtCgqkS6+eUrDjEEd22VHaDh1sQttuLVgmxE9L2otgNkgiH+pq95cbwnOwyztnvcg6Ag8ZoH/1 GnEx61SwcImEf13ppG7caDLbtJb1eDTBL3ju008bN8pMbA/40TEl8wp/y1iGI0c3XHbN656R1npe 4Uqnc7n4ardKMyoDLYYB3jetoOIyH2c4KKjwafaAPYXRjxbi1BKUgci19wA0j9sXCAqqLQBn5K2g qvZgqqACa2rKQMMxsLBVWtd+Q5y00NBWqc6O2G+1J57sPSBcKll4snfbkhJp1TpTirBHqaR9O3Eh sNziEnHCeHFKaakjJWHj0IUgcqCjZPNmSS/YIun4JV1Beppswqbw9fgQr8GTwlfn54eWhEtKl0I0 AeFlhavfwbzUydX6hpXePXwyZqhOL1oZOrbhuNCalYFmwQDvm9wuw2U+OzvVBn4KKv4E/xMVVGAh CSwiqA5BU/moCwqqfMDOUlFQ8RVW1RZUuocKbKkpAw3HwDZFJWtlFuqfxTlkfmLLW3aosN0VHfJz W3VctTbUEe9KaRuGfsJf2AmZMH5HFHZKI27YhIvSijfIyv+s3yLZNV7fL3/c8iFHnP3FNZ+Xj9WQ MqAMVMIAhVXwl34UWIRacjFgx42zjnY8azXZpIIquQZeW9vsGIAw2py9vmizYNHOn2Nuii46xn2j sDAfS4JqyoAyUEMGeBPmzZjQe2oNyUuA7BwzO34cy1qbDn6tqdOCykDzYaDwt7TJzac32hNloFEY 4CyGhZ3Z4I1ZLbkY4JjZ8bPjWasZqjqpseTiTFurDCgDyoAyoAzUKwPBG7C9KdfrAbSyBmfAjltw LGt1UBVUtaJNCykDzYeBVt3CR7fqUXJY8+mR9kQZaFAGgjfeWL/eUxuU+gapnGMWO47BcLUPqoNf bao0ozLQPBlwUkLX4wEK3DOvpgwoA8qAMlBLBnQPVS2J02LKQPNgYGkGfhO8S9Hq1f9rHv3RXigD yoAy0DQMqKBqGt71qMpAQjCQ0b33H9CQ2SJ9+DA7NWVAGVAGlIFaMqBLfrUkTospA82BAVdC+xvR 5081h7HUPigDykDTMqAzVE3Lvx5dGWhSBooL8h6UzWv4dGA1ZUAZUAaUgTowoIKqDuRpUWUg6RnY 3N57oGjS90M7oAwoA8pAEzOgS35NPAB6eGVAGVAGlAFlQBlIfgZUUCX/GGoPlIFaMZDeM3xqq+6l f6tVYS2kDCgDyoAyUI4BFVTl6NCAMtByGHBM6BRjzK8tp8faU2VAGVAGGo4BFVQNx63WrAwkNAOO IwcUlxZ9ltCN1MYpA8qAMpAkDKigSpKB0mYqA/XJQHr3oqHGyAZZ12ZVfdardSkDyoAy0FIZUEHV Ukde+92yGXBSholj3mjZJGjvlYHmycCoUaMkPT1d2rZtK23atJFevXrJ5ZdfLps2barXDt9///3i YKr7888/r9d6k7UyFVTJOnLabmWgDgwUr0p9vmhlylV1qEKLKgPKQAIzcNVVV0leXp7k5+fL3Llz 5f3335fx48fXa4ufe+452XPPPeXFF1+s13qTtTIVVMk6ctpuZUAZUAaUAWWgGgx06NBBTj31VJky ZYqXe+XKlV6YM1eHHnqoTJo0yYufM2eOnHPOOXLXXXfJwIEDZbfddpPZs/Fmqjj2008/yYoVK2Ts 2LEyYcIECYfDZbmOOOIIeeaZZ2SvvfbyBNfUqVPloosukt69e8sJJ5wgBQUFZXmbk0cFVXMaTe2L MqAMKAPKgDIQwwBF0csvvywUOrQHHnhAevToITNmzJAzzzxTLrnkEsEvfr3ZLM46UXB9+OGH0q9f PxkzZkxMbX7w+eefl5NPPln23ntvyczMlIkTJ5bl+/777+XRRx+Ve++9V4YNGyYjR4708rz77rtC Ica2qCkDyoAykPQMpPUIn5HR030l6TuiHVAGmoYBTkSkA1lAN2BrYBgwAvgTAG3StHb66acbtsMi FAqZQw45xGzcuNFr2BdffGFyc3ON67pm5syZXr7NmzebadOmmc6dOxvMNnn5vvzyS7PNNtvE7cyA AQPM119/7aVddtllBsKsLB9mvgwEmRfG/iqD/Vze8RiBvVzm2muvLcvblJ4IPxwzjh3HkGPJMeXY coxrNOmkr54BY2rKQEtiICSOvhC5JQ249rVFMsBN6HZ2iRvTMzIyynjg8txxxx0nEFOyww47lMXT 061bN0lJSfHiuKl9y5Yt5dIZgNCSpUuXygUXXOBtSs/JyZENGzZIYWFh2XG4vEfj5vi+fft6G+QZ Tk1NlZKSEnqbnamganZDqh1SBqpiwNnfLQk/VFUuTVcGlIHkZYDLcJht+l0HSktL5bTTTpM777xT Pv74YykuLvaW42xGzGZZb4UulwXPPvtsGT16dFkezIp5G9+5R4pWnXrKCjcTjwqqZjKQ2g1loFoM dM/tKo70KFl7x5xq5ddMyoAy0KwY4EwSZ5SOPvpoT/Q8++yzNeofBdgrr7zi7bHaY489ysoef/zx 3q/9rKAqS2hBnqqlaAsiQ7uqDDR3BtKk1QAj5k6RbLe591X7pwwoA79noEuXLt7sEjeLE7NmzRIK Iz5moTr2wQcfSPv27b0ywfwUVO+9955gb1YwukX5nRbVW+2sMqAMKAPKgDJQNwY4EcHVnVZAa6At 0A7oAHCNbQI2WsNJbFu1apX30M927doJlwGxYT3uEmFi96JureNDSWEnATnARmAzkAfwuQ5FAJ8F Ue0vn7rkB7bUlAFlQBlQBpSBlsQAH5tgjZvQ4+23sunqVo8BXfKrHk+aSxloBgxkh9K6F++JX1Pr zHTjjib3q50WOeRUuD8DnNmwxpkOTml0AW4HPgVi7QVEPBeJtPVdjXBxBKVwCRu+Cf4/At5P4mPc 3/9sCxnUlAFloG4MqKCqG39aWhlIGgZa9bjhkBQn9W7BS/ySptHNs6FcHrqhgq7xHR77AVsF0vk8 nKMAiqqgYSy9Z+Uw/UFgfCB8M/y0uQAFdBCZTFBTBpSB+mVABVX98qm1KQMJy4Ajof0xYfF5wjaw 5TSMQuhCYJs4Xf4BcfOA4wJpB8PPB/d8EohTrzKgDCQYAyqoEmxAtDnKQMMx4BxgHPezhqtfa64m A8uR79/AuArycybqxEDaCfC/CtTmaYjtUe7PMdgNYbUWzsCoUaO8h27y4Z188Cff68eHgW7atMlj 5g9/+IP3ME7ureLG9Z49e3q/BOQGdj7sc/DgwYInpJdj8bDDDvPeEVgusgUFVFC1oMHWrrZkBuam Y+fU7kWlOdNaMgsJ1Pd70JZBwPFx2vQS4kYAHYEU4FiAS4G1MdZxfgz2rU1FWqb5McBHJeTl5Xnv 8Js7d673YM7x47ly7NsjjzziPbMKr6URPi5h3Lhx3jv7+NBQvvz44YcfFr74mMZ39/Edfg8+yNXn lmkqqFrmuGuvWxoDXfp3MeKeJ791z29pXU/Q/vIn2fx6PxYIblBnc5cC04FjAAqywJgAACAASURB VO6nYt7aziwuQ9mDYnA/wmrKQDkGOnTo4M0uTZkypVy8DQwZMkT4DKvIowZkr732kr///e9yzjnn yA8//ODNXj3++OPSqVMnW6TFufrYhBY35NrhFsnAujYr8fOv2s5ytEjKGqHT7+EY3Et1fZxjcay4 7Edx9TJgADVloMEYmD17trz88svesp89CF5sLHzvX1FRkTczxffzjRjByVPfbrrpJu9hnhRXfJ3N kUceaZNapKszVC1y2LXTyoAykCAMXI52XBCnLa8gjpvRTwLqIoS5ZMgpg1jwV39qLZwBvs+PM07E rrvu6r3E+NRTTy1jZc6cOfLRRx/J5MmTvZch8+GfixcvLkvni49HjhwpBQUFctRR/CFqyzYVVC17 /LX3LYSBVt1LL8JkR/R18y2k30nQzUVoY7wluNWI/x/ApzZz+a+2th0K5sRBVm0r1HLNhwFuQl+3 bp2H/Px872XJfK2MtYsvvth7Px9nrr777jtvBuqBBx6wyd6eqYceekj+7//+T6644gpPWJUltkCP CqoWOOja5ZbFQFrP4mH4CnqJyIDCltXzhOntTmgJf7lHGw7YB3QyTLsB4IzROgYCNhL+wYGw9Qbr s3F/hWe0DUTct+Gy3njYHJNXgy2QAW4u56/4iIyMqr9vDR06VLg0SOOv/c477zy56KKLvM3pFGI3 3nhjC2Qx2mUVVFEu1KcMNEsGQiblAGzB+axZdk47pQwoAw3GAPdOcTmPs1dvvPGGjB07tmyf1L33 3itr1qyRm2++WfjqGs5U3X///TJjxowGa0+iV6yCKjFGiN9Cuek0Dega8T8MN2ijEJgciVgAFzMO 5YxfL3KBPwLB+r5G2L6Ogsfgs2xseAf4+W2Z8bF4BnFqzYIBZ3+jD/RsFiOpnVAGGpOB0aNHe8+o 4rOq+MypQw45RK688kpvHxVno7j8x2dY0fbZZx8544wzvOU/zl61RNONiYkx6hRA84F0gG8sXwNw 38NhgN0/QUF1LnAQcDOAp157fjieHYP/TwPdgQGArS/4MMBViD8L+BiwRkG1EGCdas2QgYwe7prC osLdZH1rPlBSTRlQBurGACciUoFWQGugLdAO4LW7MzDBGH4/VUt0BiKPgOAPP3i/3QhwKZz7FgsA Pq4kDLhAtYwnhlpiMnALmvUg4MRp3ouIwzKON5tlk0+A53WAs081Nf3015SxpMm/NKPUCR+uYipp BqyhGsova0OAvoBe9xuKZa23RTNAla2WmAw8hmZxNukc4MmYJnL26XuAT1B+HOA4cobqFKA2tiMK /Tmm4CSE18bEaTDpGBhQWLJSmnpTw6+g7QiA52x92n9R2UOAv0vWnzF4IuYATJ8GcDbhCuBAYDFw J7ACoG0LXAzw3XpTgHsAfitlmYrq4xea84Gg8fNaCvwd2DmQMB1+PsCTxs/saQDrHw8EZ4sR9NK4 7H8fAxGrqH1Mrqq+nZCHX874jXsJ0BvYG3gJuAPgt3A1ZUAZqAcGVFDVA4kNVAUvzNwn9SbwRpxj cJaKs1IUVLy4c2aKN4Pa2G4oxKnqoP2IgAqqICPqry0D+6Dg6toWjlOOXx6I/wNeCKQPhJ/7AscE 4n6O+P8Fd3fgWoDnOz8r2wMUTW8DE4EbAC59U9BcDVRW33Ckc4ngQ8AaRRKNwuo2gEsHNNv3A+F/ BOBxKOqeA/glaBowFDgeoOij2LHG5aSK2ldZfSzP51jhcRkeT/lwdwZmAh0Blr0XuBBQUwaUAWWg 2TAwGD0xQHBTenqkd0/DfRAYBUyOxNHpCxQC7QE+GIQXR2vB+mwc3VXAocEI+HlRvzEmToPNhAE8 f2qcdC7o1UjdOQDH+QCgEH8F6ADQ3gS2BvYDeJ5yBoj7uXg+9wesvQ/PdjYQccfB5TketOsRGAts BigMrB0ND2d2Yy0FEfzC0SeQsAb+Q4ATgf8F4llfDsBlsYrqY/ZngNjPEuMdgJ+zePYyIv8WSODn 1rb3SPjZp+8AxlurrH2V1ccvy98AHIPOAOu9BLgT4JcltnMqkAHQeA24COAYrAQ4TqyD1hN4EVgB fAxQqNE4+zUeuAZYAkwHdgYqspuRMB+YBXAMrfGcORP4GmCbhwMPAb8C3MbQGog1juldwBqAZc4G aBy32wD2ge2luGZfabU5jl+y/H8eIx3IAroBWwPDgBHAnwBsoVJLBgY4VpEx49hxDDmWHFOOLceY Y11tq1HmateqGeuTgWtQ2anArjGV/oLwt8AfgeMAXvDUlIEoAxBSTsg5VXJa88bSGDYOB/k3sCfA a8vFAG13gDfFTsClwEaA4moBwJufNX5BcG0g4vIGlRkTdwfCnMlZHxM/CGFeED8HeJO1x+8Lfx6w HLC2CJ5tAZbhDd4aZ47Yzi5ARfUxL49DEcCyHwJ7ALQeQBh4FfgeeATgjBCNZWKPtY2X4gsZ9mlK JGydytpXWX3s208Auf4z8DbwAPArQOHCGwn5Y19pzE9eKVIOAQ4FjgRoFGIUibsCzwCshyKlDTAK oOA6HPgZuA2IZ7xZHQGcAJwCXARY8bUj/OcDlwMzgYnAFuBoYDDA/LHGseUx9wVuBCjAyBXrPQzY CzgIOB04C6DV5jh+Sf2vDFSDgdRq5NEsTcvAahyeF6l/Al/ENIUi6iaA+yB4kayttUZBe2G1dZTA k2sD6iYfA+mt0g/Aj40+a6SWp+E4WwG8AfKY5wLtgFiz5zNv6H8DlgIhgEKKN9u62AAUTgd4g90O uBXgZ4MiaRMQtF8RoCDoD2wGrFF8sm1Mq6i+x5E2EPgK+C9AwTIJGAr0B9oCbwIbgDHASwBv8v2B YDuWI8y8lVl/JFbUPqZVVN8gpC0DaCcB5JpGsfsB4AD8Fr4SsPY0PJ9GArzeHAW8DbwHzAbygR8A cmvbzeNfCZQC/waeAmhDgAzP55dhvtOARUAngDzvBrBeGseKfKYAZwO8ruUBHwPbArHG8+tuYGEE F8Dl2I8G7gPILe1B4FTgKYBW5XGy2+CX0iGZBIJ4Hrj4Z8AWz0+3LA7PIfESwSPcEDI5Oa7M+W+B xxWPo9YCGUhtgX1Oxi6PQ6N5ocDnuZxNQIgXD36rrItdg8JE0D5C4PBghPqTiwG8oWt/3As+b6RW U4CfD/wH4Pn4KnALEGu8ofJeROMNmjcq3qDnAdbOgccKgC7wTwXCwPvA1UBFdhkS+Blh/ZMBih7e xK8HOgNB45cICq1uQDAtE2H2hTfkiup7HGk9AduPL+Cn+Dga4IwUBYNNWwv/1wCPUQCwP9bawEM+ KjOWqah9ldX3K8odF6mYwo7H7Q3sBzwAXAd8CgSN4sTaUngs17xPUCAOA34AgvYbAhRTtDyA/NFe ASgwaX2ALQCF7gnARsCKLXg9Y3tpxcAvAOuihYE0z1f+X38EfwxEPRPxM558W1sCT1cbgFvlcbLz ZXV2FtroyD4sF3vR9eIQyfgQA7DNrrzzdIE8D28HL0L/tUgG+EFRa3oGfkIT7OeWF2Drty3jBd5e nGwcXeaNd7EJ1hfM3yMYiPhHwSXUmhsDxtnflfCTjdQtzg5MA7YBdgIoYm4HTgOCxlkRa1vBQ0Gz 2kZE3E/gUuzQ3gB4888B1gCV2XAkcsaDAoJGUdAP4A2ax6XQ4TIXbQAwF+gF7AJY6w/PAoA38uFA vPraI343gKKNRvG0DGAbKQ55n50H0JYBFD4UFGwH22OtPzw2n42LdX9GREXtq6w+Cp8dAc4S3gZw LBYB5wGctfkf8DcgaOTIGstSLKUALwAcg0MBjjP7Ys21nhiX5YM2DoGOAM+PzcA7QNAqqieYJ+if j0DwenYIwozjmPYGLK+D4efMl7XqHudpFPAElS1YkbuxFA8Qz5dnka5iqiKSWkg8P/hqyoAy0AwZ KFoV2rFkVfp3jdQ13rhnAhQbc4CXAQqYWNseEQTtDICzDFbknAp/Z4CzCJ9FUAyXN0SGecOszE5C 4n2RDF3g8ovCa8BK4FvgXIB2MsB0Cgze2Hnj3BZoDVwLTANoFdVHQcEbKGekaHsAuwEfAN2BSQB5 oBi5BPgIoKh6Ezgb4HWXwoLts8eCN65V1r7K6iNvdwNPAUuAwwG2ZSqwFzADoJgM2gkI8Et2W+BE 4AuAIqgz8C5AMcIxq41RaFIoU0xRzO4LOEBNbG9k3j1SgLycBrQCKKwogDYCbCfbmAGwfo4Rj1sz y8UMm8FsGZb2KixopCgnLBdCTD1YYR5NaFEM8MOjpgwoA8pAXRlYhwreA1YCXHKhYLkciLVliHgF oNjgTe90wNoL8PCmmWMjaujeg/wUUJxVGgR8CvDGSzsbmAxcBFDoUTCEgaXA1cB0IA9YDQwHaBXV R7FyHXA/cDswBGAdLD8VmAhQXLKPFE/HATTmPxhYDnQAHgaYtzKrrH1V1TcBFa8F3gQoqhYAvYH+ wIcA2xE0tp95MoF5wF0AheBTAPtD4TsNoDj9N/AUUF17ABkfAUYDpcAzwA0Ax6u6djEybgK+A8YD FLDsF8fxTiAXeBb4GFgEsD90PwKqbTe2wab8kHfupkGSUZTFs/XrXDl1XIF3rrWNl0HjWh4DFZ0s LY8J7bEyoAzUBwP9UQlvyD/GqeyPiKPIGgn0BygWDFDf1hcVFgJrYipOQXgbgDdZ3oSDloVAV4A3 6FirqD470/QLCmyJKcT6tgLYRzcmjfXx5r8hJr6yYFXtq6o+isiBAPtnZwSDx3sOgS8BCh3OrlEY B42zQPnAZoA8UhDmADUxnhfkmHzRyE/sGHkJNfjXB3nZVoo0a3ac2dbYftg85dzzsXWiV5Y3Y/g3 SKjtvUTMQMHPGTDfOFsFgYUTdhE2oB87Ls8TpK2RSEHVDiAnnQF99QxISAar71fPpCZDp7WNdWKA Fxx+4Hlh501GrQUw0KqH+6brhu8s+S3960bu7rJqHI8Cgzf2hjJ7w46tnzfd+bGRkTAFCRHPKqqP /fgpXgHE1aa+CqryoutaH0VUPCEVe0yKJiLWVgUiyGNNxRSLU3QGuayrmGKdy/kvxiob53JZs7nM 205GY2bhKiTwWkmJvwL/H8w18gQunN87DoRfREzB/RIDcRzEFMVaVGyxnFqLZ6AhBdVYsMsp13/U M8unoT5+y7F7JVj934Gd6YnYdLg8Pu1YgGV48RsPcDqYxg/DFcCBwGLgToAfJFpF9bHME16O6L+H 4J0GHADgi045OwuhUmBbgNPV/HY8BbgHYHus9YLnfuBEGwG3svZVVR+/Ld0OsF5ewEqAg4FlAPvG /jaEHYlKlwHz4lTeEOfD3jgOx5T7M9QsAz1X8lvzoSW//XyKjUoQl+Lj6QRpizajPAOvIxgUO+VT m1kom18ys+QSCKkr0TXeT/gchB8gnv5pcuVlpHszmNlt8Xw/B7/29GemXszJlXPG+dfThrx3sjlq SchAQ54Ut4IPU4+cDEVdxwMUQS/F1EvhchtAAUfjPgjagQDX7blWTxHxHMCbDAXQv4DdgWuB3YAp AKd6KT4qqm8g0nYAxgDWfo54hsPdCHwYCdOhaOLs0NvARIDtuBngB/hqIAsYBZwBDAKCVlH7KLQq qo/leby3gOuBr4BdgVUAx6MP8ARwHMC21reNRoXvAvEEVX2fD2z7DGAkPS3dWnUL/xEnW5eS31Kf zCjtujf2gICbbYoSjBcKKkIt8RigoGr2lo0ZKSdLLjWYkYJ46uJ12MjXCN+Rnevtt4M3YC6WQENy GSJvz97sTQ4wPRTIoV5loF4Z4En5X4A3bc4M7QXQ/grwBkubClA4zAIWAMGZGN74/w8IGgXGIcEI +Dn7wVmO74AHAGv4klHjVz2koEwxQIFhbQ08PGZl9R2N9MdsgRj3GYQPjYljkH39XyD+QPhzAH4o ewLs04sAj2+tsvZVVh/L3wNQeNIeBjiDdjfwPrA/cBlwKmDtKHi4DLIcuB/gPgfaTsCnAOOfAtoB tCuBi4AJwArgZSADuBTYACwDjgUuieB5uBSgwfOhF8IfAeuB14GdgbMAil9rHeD5BmgP9AAo1DYB PIeGA7QdgBc8n7+v4y74ySPLnQ1YOx8eijyC7Yhn5DxeeY7TbcBKgP1lX3iO0D4AzgS+BnjM4QD5 /hVgv1oDjWKtuoePyujpmrTuxXtm9CzNzuhReicPzHCjNEAPogwkMAO4OLW6uZ1cdnOWrIZrCDxr 6nNsQD+4qmYjH6/7QeM1IR3IAroBWwPDgBHAn4BkeOuKthEMcKwiY8ax4xhyLDmmHFuOMce62laj zBXUegHiC4CdgCeBRwHaAKCf5/N/uXM2/DzZOEvzOMDG0ihsSjxf9N8e8G4XDXq+9/H/CmBKTDxv tmHgVeB7gDfljgCN5PAGbG0xPNsAfYE8YDlgbRE82wKV1TcI6azzc4A30IsBa4znzZXH4ywV+0Bj mdg2dEJcF2AlwD79BwhaZe2rrD7WcSDwFtAd2Bu4CPg3sA/wFbAG2AqgcXwoiP4OHAqwzRQc7YBJ AOuhCOMYPQPQ+gB3AC8BpwK8YZ8EUDiRE/I/GaBougVYB/AYwfOB4fkAhdRC4AmAouRsoA1Ao9Dj ebUJYH6ObX/gNuA1gP3jSc8ZOBrH4nBgX+BG4CGAXFHcXQeQ51OAC4HTgVirqDz5OwzYCzgIYNmz ANqOwPnA5cBMYCKwBeAFeDDA4zWOhcOLDD5HoVDqc3C7hkvdKendS19MCaV+ndG9hBcLNWWgxTGA C1MKRNR5Xdp515l78VWoG26hX5tSOQQzUvvfku9d5yrlBfnerTSDJioDEQZS64GJXqiDNzfag8AU z/f7fzchiqKFoPA4AOANiDf7uthAFG4LvAlsAMYAvNnzJtgf4A3Z2nJ4mLc/EIxH0JtV4M28svoG ID0d4A2bgu9WoAh4HGA5Cpb/An8GKEiGAv2BzYA1znLgnlcmHGx80O2PQEXtY1pl9aUh3QU4k/UR QKPomQyEAfI+FqCNAiYC7zAAuxToD5wMLAGs0Lse/pUA+aG9AlDU0Mg7uXgWyAfWALkA7VvgMs8X /bctvHsDI4FCIBuguP0pgkPgss7jgReBbQCKJIoU9vtVgO08CpgHWDsXnruBhRFcAJdjdTHA89Jy cR/87N/zQNAqKj8amViG5w6NdZ0KPAXQeA5w3FOAswGe5+zPxwD72ihWtG7Vz6169AvhYD3xvWtd SkoKeUqB//Wi1WkVfSYbpW16EGWgKRjIbit/wrLebeJ4X2541Z2NC+8YFUhNMRot45j1IahuA1Xj gVXAF8C/gOCNDkHPeKOztgwe3iR5M7fWCx570+sBfxHwF4AiYBegIuMxOwH4rHi2Fv8529EZKAA4 E2StDTyLAM4iMD1orRFYDFRWH8WBA/BYFCgUUacBjwM9AdsG1nEUQBHANgSPlYlwCWBv0PD+zipr Xzfkrqw+N1IbxeUwgDdZCoifgAOBQcACgNYf+JGeiH0Hl/gnwNkXiiNrrMcel+LKGkUUuYtn0+NE 9kfcUoBiisa+UpTQOBN1DPAhcDDA8d8NmA8ERSTF3lbAPMBaf3iCfXkmksD+7gFcHQmnwWV9sdYf EfHKM57nkzUeu6sNwP014i+G+wtAMUXjectjNZINAJ9uPm4g7cRxrsVJmo6zcW1hSc7ZjdQAPYwy kBAMcBkvJcX7kRE/97wqL8QXixuz87zri71GJ0RbtRHNiwHeJOtqpajgcICC4jWAN7K2QKxxGcka b9arbSDi5sC9KIKpcCdE/JfCrcy2Q+KQQIZl8BcAvFHzBtcPsNYfHt6EGZ8FUIhZGwDPXKCy+oYj vQNgjcKA7W4PjLCRcPmhXQYw7WegP2CtPzwUNLzhVmSVta+q+r5EpRRzbwMO8AbAmaZdgeuBCwFr FBAUr9a2gWd/YBPwMbBVAH3htyLQijZE1dgoZlhvSqQkRceoiP8VuGz7YcA0gPxxTNjGEGBtMDxf 2UDEZb3BvhyCcB+AfbkEsH1hHh4j1ioqz+P3DmSOPXZduAhUWy9eT+hi0NNxAykQU3qKrOuaWy81 ayXKQIIzkN1ads9uJ59ATE1EU/fAZ2Al5uovwK/2hkJMvYQ4FVMJPobJ3rzgTaq2fXkaBY8E1gDj AQqFDCDWTo5E8IbEbw72hsiZKs6k4Bt22esmVsC/KBL+HG5l1h2JkwCKGt6kefP8CCgAuHR0NsB+ UiyMAnij5o3nW+BcgMa2cSaLx6ysvpOQfh9AY37W9xpA8fYscDRAY/84s/IB8A6wD7At0Bq4FmAb KrPK2ldVfbeg4hsBiszzgGOBWcBhwDXAjoC1d+E5GOgHpADsWzdgCjACoIiinQZMBaq6IFFcZwKV 2S9IXAr8KZLpLLjHRPzknzM+NwMvRuJ4LiwDToyEKZI4lrEckhe2sxVA0cTzciMwGTgF4DlJjAf+ BtD2Bnb3fP44xStPjs4AWNYBOMafAIloS9go3Ei24P8LhbrUl4hjpG2qZways2Q77JN61UmVb/EB HYmL1EZ8Bq7blCuDbsqT/2ZX/uW1nluj1bVkBlLrofP3o44JwGwgC3gUWAfE2v6I+B7gDfGfwByA djnAm+xMBmphU1FmIsDyFAUh4DiAxrZRMCwHOgAPA8xLOxvgzfYioBPAG3YYmApUVN89SHsNYF+5 lPQpwBt5MXAdwOPdDlDMXA3kRUD/9Ih/NdzhQFV2NjLEax/FSGX1UdgeA/wXYH9+BDjOWwObgTGA tQXwUDDMB1YBc4A3gFJgHLAQWAy0AUYBVRmFBseWfazM2IYXAHKVD1BUWXsZnpuBN20E3NuAZ4Hr gZ7ALQA5DxqF0gcARQX7fSdA/nkMjhF547nBsbsg4r8Y7iZgBvAU8D5gy7MfbNtzwEfAIoD10f0Y YF00iiz66dJsvB/6fdjG179rSn80knIEGrKpMDz/ijhtqf9j1qxGEyd7vLg42TRKGSjPwA0Z0i8t TW7E+X4WPn0pOJEwKyv3F+bK3fjwbiifW0PKQMMzYG8CdT1SR1TQH5gHFAGxxrheQDrAGxhvVPVt WahwK4A3Tjem8r4I5wKxH7IUxG0D8CbJm3DQqqqvEJkpXoLGmynr+wXALEE5Y31dAd6wq2tVta+q +jhbsx1AIbUMqOjm1QlpFFEcm6B1QYDjRlEWK2CC+YL+tgiw76yvMuO5wPpXVpYpkEZRR1FI/ihs Yo3nMtEboDi0fbXnOMvST4FYmbE82xQ8h+y4kkfWnZDWqkfBxY6T8Z+wmzMivLrrtARspB0TNs36 6cbzJ2DztUmJwACW9nriK+INOGtGY88g9wqWGEeeKA7LLXcUNMrnk9cRfknl9ZWrDrzmcUsLv7Tz Wvqa/4t8+NQSmoHIq2dORCPXAxsBXuN5fykAqFuoC+z1Cd7Kzd5sKs9V91QrqOLNXNW9dq2hJTPA c9iexxQ+9FvX+slPMB/Dzc7SOnw6yKR2ah9et+P0BO1cUDxRsNqw9VsRa+MTtBvarKZg4Po20i09 5M3OXwQhlYFlPZ4vL4SLJfu2oiq/KNVnk3ktsYKKWxysoGoPPwXVGyqowEISWERQHY+mUlBxQsEK Kk4K1FhQ8aRoDLsNB6HiU1MG6pMBK5KscKKQIjizZ12bZvPy+PQ3OyvZeCBn1gh+a04ks9/wrFCy AoqzmPRbl+NiRRXbb8vRr9ZCGfBmpCCkIKLOxyc3E2cFz4sJYSM33ZZX7pe5jc2QPZ/p8ry153Jj t0OPVzcG7PWH4xcc0xrX2liC6tYat0wLKANVM2BFkhVPFFIEp26bpWiqmpKky8ELGJdKeFEjaFZU MU2thTKQnSH9saB3FW5x53FGyhNSRt4Iu3LzrfneXshEYcYKKZ6/3hIRZj70+pMoo1N5O3iN4ZjZ 64+99lReqoLUxhJUFRxeo5WBWjNgL1hWTPFcJtIAR6fca81roxaM3Hi4F6WE4xY4OC9wDKuoCpDS ErzZbfDcwRTMSBnv19f8gsRzYAKE1K0QUt8nEAdsF2/AVlDxHCZOAbj8x31V3PvJGeMMgNcmXqN4 zVJrPAY4PhRNHBvufeZqGfdxc3mPy3x23HjNseNZq+uOCiowqJaUDPBmywtTUFClI8ybs1pyMcCb jRVTvJBZ8OJWqwtbcnVfW5tNodFWjsO8zkU4E0ZEGCnBPqnncQbchaebz0swloLnqJ2Z4k2b+254 0+a1iGKQxvOYP+qxcSqoyErjGfnnGHEMCO6PoqCiy7Gye6XsTJW97tT42qOCCmyqJS0DVlTxwsVv fxRTvDmrJRcDdsx4AePFzCK5eqGtrTED2Zn4VW6anI/ZqNEQUj1YAU6CPPx7DHMK/8neUvYmghrX 3YAFrJiy5ytv1vaGzZszb9RWTNl4iileoxhvvzzAq9YIDHCcOA6ciaKgoogKiiqOGePtOAYFFctW 21RQVZsqzZhgDMSKKV6seNGq6sGiCdYNbU5kzHgR4wXNiinrKkHNjwEHy3qHYG75QnyIj0H3UjyJ YfBWBINnBebJs9n+ckyi9zwoqHhDpljiPdXeV62Y4s2b1ybG21l1eNUaiQF7LeEMFMcpKKq4/Gdn qayoYv4aCSnk98wOvA2rqwwkEwNBUcULls5QJdPoRdvKGSo73U6XNx39Fh/lp1n4stvKDhjVUVjW Ow0d6sNOYUmPN7EJkNEPZ+d5b8pgdDJYUExx5sNuPbDLeTyPOfPB65IVUxRcKqhAQiObFVQUuEFR xfGxs1U8D2P3UtVYVKmgauSR1cPVCwO82VrYCxkvVlZU1ctBtJJGY4BCmBc0XuDsTceOL90aX9hQ Ri0BGBiTJYPTjPwJD948GUJqp0CTlnrLekaewP6o2AckB7IltDdWVPFcpfEGbgUVZ87tUp8VUzYf 86o1PAN2nDguFFVWONG1y310GWa6zlCBBLWWxYC94VpBxS8HBG/OasnFAMeMyyIcv1hBlVw90dY6 eG7UbhjJoyGYToSI4qyU9+0HdzU+PPGVUiPP3ZrrvYszmYWyvUnzOsSb4tzUFAAAIABJREFUsBVJ jGeY4Llsz2k9r0FGExnHxI6XHRsKXvqDM1M2zs5osUyNjIOtpgwkKwO8iNlvfbxg2W+Dydqfltpu O272psMxtTeolspJ0vQ7m08Kz5KRaPDRGLQjMXI9vMb7I7gBy3pvIW7Cys3yyaP+LEDS9K2ShvJm yx7y5mvN3rQZx5szz+fYc5plfGbgUWsUBjguFlYsWWFF185M2Tg7pixTI1NBVSO6NHOCMmBnqXjx 0nM6QQepkmZxzII3n0qyalJTM3A+vrj0zJI9cIs6CDNQB6E9+0AilM0M4y70C+Lec0vlrdX5MrkZ iahY6u0NN3gDtjdse02ieKI/KKRUUMUy2bBhO050CY4RXQoo+q1rx87mQ1LNTG8+NeNLcycWA/Yi ZS9a9iKWWK3U1lTFgH6Lr4qhJky/FMvoHbJkV9ws9kMzRmA/1P74wLW18yzeO/WMTEPcu3j45rsJ 9vDNhmSON15rvCnbmzVvzPbaxGsSzYb9kP5vCgaCQsmKKjtm1mW7gvlq1E4VVDWiSzMnIAP2QkWX Fy97AUvApmqTKmDAjltwLCvIqtENzcANmdInLUX2xnH2xgzU3ri7DIPLH3x4xkGCiJoHiTDZNTK5 OFem/lNkQyS5pTn25ktaeJOmWUFFP+OtBf02Tt3GY4BjZc367fgxPui3+WrkqqCqEV2aOUEY4IWp IqigSpBBqkEzOGYVjSfj7cWvBlVq1qoYyOaXjywZhIdqDsOs0y4QTcMglCietipX1kAgGPkegzDN ceVTuFOy82V1uTwaiL0Z87yNtXhxsXk03HAMxLuOxIurdQtUUNWaOi2oDCgDykBSMODckCF9U9Jl aMjIELR4KO7sQyGidoTrLd3ZOz3EFNXreoisr+H5CgLrq4J8+fpukdyk6GniNDLejTpeXOK0WFtS ZwZUUNWZQq1AGVAGlIGmZ+D61tIjPUW2xlzfQLRma2AQsB0BncQX9JZbgIqIqOUQTrMgrmbCnVlS IjNvL5Sfvbz6TxlQBmrEgAqqGtGlmZUBZUAZaHwG+Mu6rhnSMy1N+mDZrQ8W63pDBPWBCOoHYbQ1 /APKRFO85hlZhemRHyG2fsQC3jxs8vmxxJE5d+ZKTrzsGqcMKAM1Z0AFVc050xLKgDKgDNQLA9lc cmsl3UvTpRuW2bpjM1k3iKVuEErdIZC6QSj1QHwfiKFuWI7z9wfyN5EwpJfNONGP5bl1cBejzGIE F6PcYjwMaUFKrvyYLbIRcWrKgDLQgAzUm6DKzpL38IE/0mur4WcblwQYPuCeW0XYxUWA+dxIfvx4 JBKO1vW7NFTOX1NEwc2Tfh3ecyVQp+eizlLU5qWh3lIvjHxMpx+N9d3I8yjQDzzMFw9mQzzqi8Kv rxQ1hXFsGx/1I55lUSbM4yBPGN8mvTD9XjzTWR550KFoWqlXZxht8tKQ4rsIe3EhhIt9P8MGYZOH OlAPnkoWzgfwvBeWwaHVlAFloLEYyOYrj7KkXbhY2qemSHvInnb4vHfAtaUj2tAJH8jOcDsjTNcL 0894XC/4HkP/4WmILLOI33PwD+KI16lf4V2Ozz+X6X7FMZbjWvIL/Euwz2mx7nMqY089ykCTMFBv gqpc6x3BdQIf94CVCyC+2uHYiuKULTtMTKXlgpFAMM762ViaDZf5gxFejsg//3tiMMb3B+LLigbi mMmLj8RFvmj6ZcsFEBVvZMp+uOwXwWW7zDrAdzOAiy6FZwkO5Asy47u4eP8uDv3mE2IpHCkAfT/L RcqwnjKB58dF6/BFZVkZCMdoGutAerljIo55oCApQH1ERCOPkcK2hANpNg9jrZ+iEiIS7ygpXYKG z8PDIJeBUohJNWWgMgacbDxLCW9BzQy1lox0VzLx+coopZsiGSlw3RDSjLTBZ6INzsc2EDBtcP62 xWehDc4/btz24nCQtkjPQnw7fD7aI097lPFEUVrZoy3LNwX5ypkN00V5vu1+NY73G13UTfc3fH5W 44P8G9JXu2H5dcEWWTnB/3KHZDVlQBlIRAbsZ7s+2+bVmR3RDnMj7vYRd2XE7RlxsYDvQDuE2vvh EK4u1DehzEi4KEscXKc4fxUqNr4LXeGF0egQ48vcdN+P6aUUxkOjeC5u4im4gHp5Gcd0HgMXUFxL JQUZUzAlloKKvPxIo5tqEI8LXQouasyfArHiuagptcwP6WP9mDVKZTm0h/KI/hTm9VxfIvlpjp/P O46Nj8R55RjHsF+H78aLi58H1bYwwywmeszZOgyFlBbjxtmpcxcJpWLQUzAEdAEHAx2Mc5iW4qcx nxdmXuTz0/z89HvhQLxNjxfvhELecb1yTsSPOC9s0xhGmo1jmbjAicBPhJcWcW3Yug4/MYE83ugz DoaSnst0LxxxY8OGzNHgBv1eFOmNF884F7+oJ0oxCWz9dE2cuEi66+XFRG04LFdfdZVsnSIvZjhS lB6SEny2S/EeGhcnvcEHkq3l59b/DPBZSMZ7HlI6ulXez1kipvnPS7L+DMRloBJP8Hj9a4h/Bl88 RDbh2JvR3k2gZZPn+s9m4vvrcnAd4V6l9ciXg+tPDi48OXh74fpsX1A1RKu0TmVAGWhkBvyrbCMf VA/XcAycBDHXHeILIhSrD5IaypJUzAyl4lt5mndj4s0pXVLx7dwPU6hBbkI18n1qviBEGALTS2cd EQEZTUcctEC0PMVnMMwyTqC+QBg3lt8JRNyA/LrjC0Q/vy1n87DOSBxumDHzgA3Hr9acnAzgHCvE OVmI828LXYQ9Nyacj3OKyEMeTnzm4dzKR14vDjNG+fgSlo/PTi409qZiVzZtyZfNY/0XOycnMdpq ZUAZqDcGVFDVG5VaUSMyQAFFocVFFv4cvC3+dUJEJwjArlgSfDZn3VpvBoSzIZwJIQxeLub5I3Gc VXFL/TRv1sTmRT4/zc/vzb4wLRBv0z03Jp4zNWX1Mc3O3KCOsrQqZnHKyuDu7s0Oefnhj7hMLxeP u75XBi7jaf7EHT2RcMT9XRhZvFkuFuKckOfAtX6oC/rL8vgZvHDZrBpn8YKzbJXMvnmzgZHZwn/d cw8ekCSvpTqSlwqxkgbRAhQgvCXVlcKQI8WAt7SMJpRg4qsIzSnGklix59LP3YWhSLgk4ke4MF+K MDW1JVtQhnSoKQPKgDLQgAyooGpAcrXqBmPgd4IKR+KOMm4l48bfCWXLVgioJS4DEZGGiVVvSYy/ RNsM5AHcW0QhxL2AUI9qyoAyoAwkNgO6VJLY46OtSzAG1q5dK/PmzZMtWzAPpqYMKAPKgDKgDEQY UEGlp4IyUA0Gpk+fLttvv73svvvucuKJJ0qnTp3kpptuqkbJirMsWLBA3n777bgZvvrqK9luu+3i ptnIbbfdVh544AEb9NzCwkLJysqqsF5muuKKK+Qf//hHuXIaUAaUAWVAGVAGlIGWxwC/CPAhEllA N2BrYBgwAvgTgBW/+rOVK1eatm3bmueee66s0mXLlpmtttrKPProo2VxNfW88MIL5vDDD49bDMLI LF++PG6ajbzxxhvNiBEjbNBzIdBMx44dTVFRUbn4YCAnJ8esX78+GNVkfo5VZMw4dhxDjiXHlGPL MdYvfSBBTRlQBhKfAb1YJf4YaQubmIH77rtPDjjgADn99NPLWtKvXz95+eWXpUuXLl5cfn6+jB49 Wvr06SMQOfLNN9948XPmzJFzzjlH7rrrLhk4cKDstttuMnv2bJk/f77ccMMNMm3aNLn00ku9MOsf N26cDB8+XBYuXChXX321V0cpNrNfc801AgEne+65pzz11FNe/KmnniqfffaZcBnS2uuvvy4nnHCC pKeny8cffyw77LCDtG/f3ptV++03PuJIBMJQXnvtNc+/YsUKOeyww7wZN5Zj22gV9cdL1H/KgDKg DCgDyoAy0CwYaNQZqqOOOsrcfPPNlc7iQAyZ4447zmB/lXnxxRe9WSLOBEEwmdTUVPPXv/7V/PTT T+b44483Rx99tDeDNHbsWAOhZjgDhiVFbxaMM07vv/++V27w4MHeMSHozE477WSwRGg++OADk5mZ aSC4vLRddtnFPPbYY56/pKTEdO7c2UycONH88ssvpkOHDgaiykBwmb/85S/miCOO8PJdfvnlZsyY MZ5/33339drG/BBwBoLPi6+oP15iPf7D2agzVM3iI6mdUAaUAWVAGUhGBhpVUO23336GoqYi4/JZ SkqKWbp0aVkWCqNnn33WE0YUOeFw2Ev78ssvzTbbbOP5g0t+FFQUXuvWrfPSKMSsoNp5553LLTc+ /fTTZu7cuV4+zHyVCaVJkyaZHj164EkOpeb2228vi2fG1atXU7iYTZs2GSuoKPBCeLwtNth7dRUU FJhbbrnFUAhW1B8vYz3+Y5sALtPqkh9IUFMGlIHkZUCX/JJ37LTljcQAl+q4STzWIEjknXfekSVL luDxUK63HMdlOeLrr78Wu8TWrVs3gUDximMvVoW/EOzfv79AfMUeRrBfS4YMGVIWf+aZZ8rQoUO9 8J///GeZPHmyQCgJl/tOPvlkPOk9JBB3XntsIbahTZs25ZYHWe+AAQMkI8N/kDhmvrzN6ixbWX9s neoqA8qAMqAMRBngwxHVlAFloBIGuA/pX//6F3e6l3u45R133OH98o9iB7NLnoihaKFt2LBBWrVq 5e1JosCpi/HXfqtWrSqr4pNPPvF+Acj9Wn379pU99tjD+1Xfm2++WbY3ir9I/OGHH8rKcK8U20Zx aI31rlmzRrhHi4IPS4bevrA//OEPFfbHllVXGVAGlAFloDwDdbvSl69LQ8pAs2TgwgsvlLS0NMnO zhYs3Xl95OMO3njjDW/DOWd5evXqJVjC89Lw6zxPaHEGqzKjCKvO86yOOeYYr278cs8TVmeddZZg f1RZ1dycjj1enoDba6+9vHjs0xIKr59//tkLs70jR44sJwgpxtj2V1991cuDpURvxq22/SlrkHqU AWVAGVAGlAFlICkY4BeBRntsArcM2b1PrVu39h6XwEcmvPXWW2W7ibDs5m0Ix2yVt7n8tttu89K4 FwozXGX58Cs607t3by/MPVesB78C9DalDxo0qCxfcA8VZpe8Tek9e/Y0EEHm/vvvL8tHD2aZvP1X +NVgufhzzz3X4Nd+BjNOBsuJZtasWV663UPFAB+zwEdCbL311t4xZs6c6eWpqD9eYj3+wzjqHqqk +MhpI5UBZaAqBpyqMmi6MpCADFBQlXuXH8IN/uoZ6AhvPxP3F3HprNy77dAAziBxVgrCp+xxClVx x2W24uJibzmuqryc+WLddj9WVfmZzqXCjRs3Ch8CWlE5Hh+b4b26g3XWpj/B8tXx66tnqsOS5lEG lIFkYEAFVTKMkrYxloEmEVSxjdBw3RlQQVV3DrUGZUAZSAwGdA9VYoyDtkIZUAaUAWVAGVAGkpgB FVRJPHjadGVAGVAGlAFlQBlIDAZUUCXGOGgrWhADeMhmud7yl4PcH1WRVZUerxz3P/HZVGrKgDKg DCgDjcOACqrG4VmPogx4DPABoXymFY3v4ONDOvHrPjnwwAM9Fy889tKqkz5q1CjvnX18WCifMcVH N+AXfJ6Q4rOl8Cocb8N7WYXqUQaUAWVAGWgwBlRQNRi1WrEyUJ4B/jrwqquu8l50zJTrrrvOe4Dm okWLvKet83lQTzzxhPfE8+qkMw/ry8vL815mjNfRCN4DKOPHjxc83sF76TFfyqymDCgDyoAy0PAM qKBqeI71CMqAxwDFTpcuXbxX0zCCr3jp3r27J6oYxouO5ZlnnhG+goZWVbqXKfCPD/vkQz6nTJni xZ533nmCdxB6T0IPZFOvMqAMKAPKQAMwoK+eaQBStUplIB4DeKin9zwom3biiSfKFVdc4T3b6ogj jpCDDjpIDj74YJssVaWXZYx4WP/LL7/sLfsxqmvXrp6YwouXy73XL7achpUBZUAZUAbqzoDOUNWd Q61BGagWAz/++KP3qheb+aKLLpKPP/7Ye2XMtdde672X79hjj5X169d7WapKZ6Y777zTe8Aon+e0 6667enVwlsoa92cF3+ln49VVBpQBZUAZqF8GVFDVL59amzJQIQN8ijpeO1MunZvRueeJLy+eNGmS UHTddNNNZXmqSucmdD7lnMjPz/cEWvv27cvK9+vXTzZv3lwWVo8yoAwoA8pAwzCggqpheNValYHf McCXIdtHJvB1LxkZGbJ48eKyfMOHD5fRo0fLggULvF/nVZZuC2VmZkrnzp09MH+s8ZeEfNmxmjKg DCgDykDDMqCCqmH51dqVgTIGdt55Z+Ev+mh4abG3r4m/wuOv/2gFBQUyceJEYb6q0r0C1fi3bNky 2X777auRU7MoA8qAMqAM1IUBFVR1YU/LKgM1YGC//fYrE1Qs9thjj8k333zj/epv9913lyFDhgh/ qWefRVVVelWH5sM9c3JydIaqKqI0XRlQBpSBemBAX45cDyRqFY3OAL8I8BeqrYDWQFugHdAB6AxM MMbASSzjHqcdd9xRZs2aJe3asbkibCcfj5Cbmys77LCDpKSklGt0VenlMscEJkyYIB999JE8/vjj MSmJE9SXIyfOWGhLlAFloG4MqKCqG39aumkYSEpBRaoeeeQRb5P41Vdf3eDMjRw5Up5++mnvCeoN frBaHkAFVS2J02LKgDKQcAzokl/CDYk2qDkz8Je//EUGDhzY4F3cuHGjULTxdTRqyoAyoAwoAw3P gM5QNTzHeoT6Z6DGM1Tc+B12S6XURNyyMOLK/G7A78cH89NfGqmDZSoMI83FUl6p8evw/Yzz62c5 66cbTPf8OAYXLG1aPJdLgczr/ZXz++UY76VH8lg/h4Jp1pDsmY2zS6XRsOA5V34eR/AXCfj+aDx9 TOOf70cYfyEnBATdoD8k944dK9K3w1uS6hRIasoWSQttgVskKU6hhEJFKFyMakpQZxhuqefST7gg mG5KJOzFh4rBQLGYiFvqlIgpRTgFCBejXoSLiqU0rVi2/FYs4xYhf4AQBNSUAWVAGagNAyqoasNa spUZPjxV+mPPUWsgHUgBQoADpBWneG5pepqklmADj4O9SWncn+TDmLQyv42jy7LBcDy/wZFCUr48 45xAHMPxygbjeKyK8hn0SCJtNKjXIG/YzWqT1dYTNBRRYQgcNWWgYgZMIdLiw8iWaJqzBeduPja+ 5eOcKxAJ+X7GuYhzgFBKPk48xEueOO4mCedvlrum56IOPQkrHgBNUQaaBQMNJaiC9fr+k3Apoq0d 7rvb5vruhkJH2nQNScciXJaKcevMCknbEke2hB1JyQxJBlynOCTFrR1JL/X9JZlwS3CrdlFHGmYr wiHoAN8VuqVASkjcEG7WEX+KA7+L+BDiS+GHG0KcCfiZ7iKO8czjpUfK2XhPELCc6wsBh36KhEgc XSsA6KcwYN4yf0RAxIbxFdrL6wsJ67duVLzYckHB4R2jAmECFkl7SzfOkqTidEjBjInnYvj9MOLK /KGA349n/vLpfh2M89PihL1TC8Rj+JmPxy7vZ5xfb3AGh/V5edFOfjiCaeVneXC6e7M+nAPCXwV+ lrGzRtbP84BlrCGLZzaO+WnRMKQDZrGiM1b+lBbD8Wa3ovn8MtHZNc6Y+bNxQfeKK68UGdjxWWmV ukXSMSOVnlqCj3SJpKe4IA3EhdigiLiPc47bz4Mxkc+Igx8qeAIbQpti20lHZyDqje/3viAgzoYd 74cN7HLDGaf9PCHmbMJx+ZRVC4RlI+LwaPxQjucal/71uP6sFyecIwWyXsZ+RVGnpgwoAwnOQPTK WteG/mPEe7hoHFnXarR8QzBg/CUSb0kksDxinPJLKOXSKyjj5/GXYMrlD9TLeLs840aWa4Jx9BvE 2zy2HhNTRzA+FFnewbqNN/WUj5WaDYUpsmFLKtxWsrGwteQWt5GikvYIj8/dlOsJJiuerFBoCHa1 ztozEBmXk1ADBAXFhSc28uBiBkiKAJ67DTm748jZw1vh96EZkF0ZkGwZkupm4tzEU1KdDN+lHzAm U4zTBiq1Dc7fNlC8cN1oWBAnTDf45amDn3EaAK4xWZ6yRSW1tALU8Rva8huO+xvq9P0u4gRhB64x v8pPOStkwlwuYaopA8pAEzDAb3X1b3YjBmt2nOhXWi8c+V5rv8oy3fPj66uXFy7DFfkxj44LCOqE a8vRjyubFxd0vRt2JM0TD8yDi7NDIeEdh4KCcXSBSLz1e+WZD/H0G9zUPTcQ5gW/LC3k56EwCMYx D8vavDbMfFYoOCl+ut0XwjxMKycyImLCi4OfLpFainwuj4F9JaUQHCVhKSoIy+pFYZng9Q2HblaG mUZv1iL2sQkUet6MXNtWmc2qw9qZBmPAyFNT7XJfQx3Ekav3xaM90tpLSmk7LAu2wyULrtMeV58O uB51BjrhmtQJn2e4gMPHf0TixGmN9AGIH4D4qHmTdwwikvHbdTVy44i1qGM56voVcb+i/uU41nJM vi/BtWGx3Pn52mgF6lMGlIH6ZCD48azPerUuZaAhGahIUCX0c6gakpBkrTsBZqgSn7qLhreVTsXd xKR2wzIoXEK6QZD5riPd0YneEFE9oawq/5JsDPZzOUuQF5DFHhzzk4QL58kdX3PGS00ZUAZqyYAK qloSp8WalAEVVE1Kf/0dXAVV/XGJmkKYCeuOPWi9MaMFpFBk9YG/HwTYQPgHwt+xwiMaswFp84Af Mds9D9tM50m4YJYKrQoZ0wRloBwDKqjK0aGBJGFABVWSDFRVzVRBVRVD9Zx+7X4dJS0N4qp0a+gv CCwZhBmrIRBQQyoUW8asQitmADOxtWAmfgM0Q/45dVk9t0yrUwaSngEVVEk/hC2yAyqomsmwq6BK oIH8+/Dukglh5TpDMdcFkSU7QGztAtHVPk4r10CEfQV8KU5omiw30yN70eJk1ShloGUwoIKqZYxz c+ulCqpmMqIqqBJ+IB0Zsw9mtNKH4cdAwyCw4Dq7odVbxbQcvy40mMVypmDz+0TZtPJLPDSVv9JU UwZaDAMqqFrMUDerjqqgaibDqYIqSQfy2v0G4vm/+0Bc7YMe7AtgNgvzWtaMwbOznM+xRDgRP57+ WG79YrZNUlcZaK4MqKBqriPbvPulgqqZjK8KqmYykJfu1U46tt4bS4AjsUQ4EsuFO0NsRe8vRn7G DNebmMV6Sz6D0Jo6lc8XU1MGmhUD0RO+WXVLO9PMGVBB1UwGWAVVMxnI2G5ct39XPG/rIDwV7hCI qyMhrnoEsqxH3Lt4PtZLEFefqLgKMKPepGZABVVSD1+LbbwKqmYy9CqomslAVt4NR/4xYk/MTh2H bMdCXA2JZjfrsDQ4AUuDz8qtn34VjVefMpB8DKigSr4x0xb7ezX4AMPYJ6Xrgz2T7OxQQZVkA1Yf zb1uv20lJRVvd3VOxfLg9tEqzXy88PFJcQuf0WdfRVlRX/IwoIIqecZKWxplQGeoolwktU8FVVIP X90bf/3+O+EF2KdjluqMwLIg30f4vITNf+SOqT/U/SBagzLQOAyooGocnvUo9cuACqr65bPJalNB 1WTUJ9aBT8Juq8HDj8CM1WgIq2PQOH7GsUpoPsJm9nvklk8/8cL6TxlIYAZUUCXw4GjTKmRABVWF 1CRXggqq5BqvRmktH8mQnnY5Nq6fC4HVxjumMd/jRc/3yJeYudJfCDbKMOhBas6ACqqac6Ylmp4B FVRNPwb10gIVVPVCY/OsxHtNTupfMGN1KTqIFz/DjFko4mbLrZ+9hJDrxSXmv3j31nhxidn65tkq E6db8eLiZKtelA5w9XjSXInFAM/bijald0Laa8bU6+cksXrfjFoTEVQnokvrgY3AZiAPKAD4pG0+ rygZB/MfaDefKM5ftl0MPAAcDEwGrL0Fz4fANIDvyusFrAasHQ/PU0A34O8A67sSmA/Q7OegxA/K T3B3BMhbeiQu6HAp7d1gRFL4z98tTbq1wQb2lBvQ3m39NhvsrXKulVumvJcgfeBY2PtprN820abb sLqNy0DwOmL9dOP5a9Uy3pTUlIFkZsB+IOjyG2sif2tNZp4bsu123IJj2ZDHa4q6KRbHAbsAVgDZ dvAp4hRDFFAP28hI+A24hYG4JfBbsbQ//BRI8d61x1/PzQOS3x6dTr6ekZOw3Df4wDMl5NwI7cIn s7+LxzFMxouer8KM1cwm6mhQPHHmnGHrWj+bFszHsFrjM2CvLzwyrzk2bP10OU42Ht6amQqqmvGl uROLAXvi0+WHgShNrCZqa6rBAMfMjl9wTKtRNGmyfIaWcj/QZcC/47T6RcRxps4KqjT4OaN0ClAb I4/Nyybws/3peDlpewirrhd6wsqRg8SEpsuNI56ScMF1jfy4BSuSrHCikCJSAq5Ns3k5JvSrNR4D 9rNgry281tBvrzvW5bgwzZotZ8NVuiqoqqRIMyQBA1ZI8YPhLRFhKUkvWkkwcGgiL1ocM46dvbDB 2yztr+jVF8ALwMqYHnJP0I1AZyAHGAHw8QGTgNrYkSi0c6AgZ7neDIST1zthLnm5Ty4f/rS0kzHQ J5cgfI6ktj5Rxgy/Rdbk3i/+rFZD95HXGMKKKAopgrORev0BCUlgvP50AOz1h022okoFFdlQazEM 8ITnyW8FFZcGCH6r5zJIO4CzAq2BDIDf+vklghdAtcZjgOND0cSx4Y2d+6PyAe6X2gTYcbOCivlr fDFDmUQ3LsGNBzhDdVpMYxciPAv4I8A8JwATAHJSGzsJhciztQ3wNA9BZXt071QKl6tkzD6Y1Usf 6z1uIeT8W7q1+z8Iq0vktqkTbdYGcK1gsmKK1xWC1xhH93A2AOMNUGXkizcfEM1rkB1THomfO4Zr dB3iCaCWOAzMQVP+CfAb7FRgAMDXNNgLIweeN6SuwBXAfsCBQNBYljekUYCtrzf8twE0foOi2Qv1 7fDPBN5iZIzxWJkxcYkS5IlOWDEVhp/ghly2Ox2wfWUefqu1cSoM6elBAAAgAElEQVSoQEYjmh0j jgGxBaCgosux4pjZ8bOiyo4vkpqV3YzecL/U8Di9sst+TyPtWOBPcfJUN+ocZPz/9s4ETorifP/N fQiCeN+LeN+Kt0EgajTiLRohmkii+f2jEoxR44lRMMQrKlHRKNEgifG+4hUVUIwaxYt4RggoGhUP EDkElPk/3955tRlndmeXZWF3n/fz+W5VV1VXVz/VXfVOdc/s6+UWbtDlhj41We0/UI/99tGIcIWm wU3kXD2i96tu1a+un5xc8PR7S+H8mqlOxpGsQ8X4whhta1gK8GGb/sRi3Im5hbBss0NVtlTLpCAr LGflKWwAg+/pYjUxPZ/JDd1H9MtvR3CRIoANF6zYHMtG3vhU/KrgRc+GYIUXPZMwMFkzOTNRhzMV 6WjDp0fS4+ZR1FYPCtBf9AOfAukjnKisU0WfkR79iAOW7WNtNhqbpTPhvr1SvFNwVrdomw8++wg0 eUrYylXg/LEPJz/rvpVWqPiwOVh3+RFJizb7abXqN3rQesVS+P2qcKoYUxhbcKaYnG0NS4HoM8Yc xp6gxmdhh6rGktXrDjhBp4obBY8EsqavDaff4jlY4R/zGXsqZNJ6JL/d2IO4AcJpYmDjmo7rOtKZ vHGoSI9PlYra6kmBGKBYhcJxyjpVrL7GKlU4VeFQ1VPz6v0wo3TE/xN7ifsyR2cl5VnBtwH/Jri+ a2udtWOXgp1ZFcRRa7xW+e7URclZe9ycNG/OY8DDdMdfkuyROybZvdfPkwvGPVlHJ1/oTOFQMcYs ryv6dXTajbIa+owxh/kixqoIa3TCMfHUaCcXrjcFpulIvG/BALtvkaP+VWmHiXCoDlX8doFTVVPj naMjC3bCiXu+IG152cw6U5xvLL0TYvH4j0EunCkcLjtUqFO/FoMTA1bWqWJyj9UqnCn6EWJgWxKH QtUst8Z5DRQ4T4XGPX2tYAV6SeypIjsfq7SRRdIbX9IFTzB29tXq1L664zV+6mcWmueeSAb3GpXM XXBacslT0+vgpLNOFWOMV6jqQNRlUAUrVIxLMT4xR9TqKUatdloGJ9xUDjlRJ/o7waA6TlwveDGV x3GsVD0gmIBWFR+LruJNsbrgUcL74nDxuMCy9VWmlH7kxzELB3heYh0eOy5nYThGsSoVnxAZ1GJw Iy3IOlO+7uu3M8P5jU+B4TgR4lThTEVIWgxu4YgpyWYFaqnAwA3bJJ3WOV2O1emaJzV55mZq7e+c 5I1xIzS6MonW1Bg/GE8YWxhvWOFoLzrmecIvpUuJBmD5L4PvoaZ+nocVc55oMB7Fh7uyP9h5hUqq LedGxw4SV4lxImtTtMEK0gHibUHZJ0RtbKp2+m5tdlxG+8QkzeDGoBhOEulsQzhbhOFQUS7KKmqr BwXok+iv6JtwmrIrU5EWjhT72KzAkinwh0kaFyedp28Djk6atRmux4D7aQT4Q7Jpr58lg3OD9I+X x9biADGO8MEuxhnmUxwsW8NSgD7DiaL/lmiesEPVMDr+fjXz5+LMIs29WWk89psibhFNZRLiPBnU mHzDSIvJmMk560gx8MUgaIcqFKufkH4Jon/CsSKMT4KRFn3KPjYrUDcKVH4bsI++Dcg3KH8vx2or DQljknN63ZHkFp2aDH1iStEDnd3rXK2hjkwuGvduQT7jCONKOFWxGl5QzJvLuQLRb+FMxVxR42bb oaqxZMtsh5N05BeLHP1Wpf1W8Hs+fFuvtsbF1KXIzjOUtrxObNGu7AQcE3YMcjHohTPFKdqhKtLR SzEp+okQ6CNCHCjiEUbfRTll2axAHStw/th7koEbPpR0Wvtk/dr6memL681aHCDH6mr9QM0FyaXj eJ2i0s7osWpapm3yk+SMXvskw8a9EVmZMMYaxlDPqRlhGkiUPst++K51s935tZau3necpCPyPlPh KtUHSntGrCt4/Fdb21Q7flJk505Km1UkfXlIYuINY1KOyZqJORwoBjsstiu3/HdZKJB1lMKpij6L kHZlyy2LdjbmYzJOdBBTBO9jZo17BVjdrS/j24gz8wfLxpfu8SsfAw5LTtv9z0mb1sM0Ohwlx+ok /QzwT/Qi+0XJgoXDk4v++XnSsuUANYR3MtfTG1Pjk7N69EkuGP9cvnExphCGdkzMtoalAH0W/Zft 0xqfBTvbrEBjUCBuBM6lMB7n5+s9lKj/8GIdcrb4Tf7QOE1Y1nnKxitzq//bX0X4ksYVmaKnKr5N ZpsPGpfltw9SyD44dDeIfwiM9yj4/aKeYrIYJt4TWKn62GdkWuKbP1cr+pTYQ/zsm+Q09mP9xfHf WJwgNhJjxaWC9mA/EYcIXo7lcT6P+3kkWlX7qqpPu6b/MeAChWuLdwT17SmmCs6N88VY4ebVgu+z sRRsV9WJ5nx4W1XwJRs0Pi4TP1jx+rcze2ydtGjxOzlVce6fJrkcP7twjBrT7esG5fSDtLmvDtXj QfqNPuFldBxUfjMQh5BV/jv8UrpUaACWfymdV2Y+FTj2LB4wTnH/8U4yHy5yoizzClVZMrlQA1CA iz574RdznoqlNYBTaxRNPF9ngdNQuPqR7bOanOjmKozjgRP0t4Idf6ztoYKBEfugMkidpWsUP0vg RIwWPxA4QDh8Owh9EyzpLsaKLQTOR6n6NlDeluJsEfZ2PtJLIQP0Q/ltAs6fyfde8aigHecJnIvT BG05Nw/tu1KsLq4VpdrHpF6qPmWlx7tHISvbT4vtxftiiFhXjBQ4MbR1adsLOsBe+YOgcWvBsffN xBVdBvbb8RN1VH4EtJce8dEne8iZQqPFrRn/yqr535PT9xiQ/O4JdGdMydJ88R281QAUoM+yfVgY zzWAc3ATrYAVaIQKrKJzwgFg0mZlaGeB/UIcm8Yqv616lOIvif8IPiGGMfGzYpG1o7WxdzZB8f0E q04TBI5HGIMhxy5mfGnjV5kM9rtOtBALBA5G2HRFOGZV9e2vfPYvZqOU+L0iGZzrM5n0norzqJ1B /XpxkggbqMhjoqr2VVUf9bD6heOJjRBXi4sEq0M9xCDRT2AHijFipPhIPC42EtiJef6iMBzI8xR/ Q9CP9FvYg4rgKNE3UwT7YluKv4qu4jUxS9AnEee4hba2Eh4WrCDcKbYR2Jri7+IzwfF7CWxrcbM4 Q0wStwv24VzeFtn+12YJO6d3T728/qHIFeWcXouS075DXTi83cR2orfoK7RAZWsICtBX+T6j7+hD +pI+7Shw+Lkvy7YaFS67Vhe0AlagqSrw/3TicwUT25/EHwXWVayfxpJkV4XHCCYfVmlwJBi8MByb hWnsmz87KrrpN5tpDIfgl2JsQToT7ZeCifTfghWplQTGYMnkGzZZERyG9cRsMU2EMRlvLKqqb0Pl U+d48aw4QYSR/iPB8Vil4hww9ilsQxelrSIGi6yDhsND3VW1r6r6tGu6KnePwjUEuh8vLhG7iacF juNqIoyJ5WOxZz4cnc/AsTk/n4YTxOTD47FDxQ8E9Yazs5XiZ4gBgmNdIdoLJqntxbvi9wJH6teZ +LmKFxrHwmmj7rdEOF2k078VYqi4Q3COWkFKf4uPSbG/4Lp5QtAG2nixoB1V27z5r8stWgnXqGTB tq0uSU75zmkl853R5BSwQ9U0uryzTpNBjoHbZgWWpgJMvBX5A1ylsF8+XhgweeK03CaeFHsIjAn4 RiK1tA20XwdxtzhdMBH/TWAV4jMieZumkLIVIpuuzXTSZ3Kuqr6uyscR5FxuFOeLYwXGfh+IgQLH 7TGxjqgQs0TYe4owaXOs/4k5AufjGrGzwIGoEKXaR16p+pSV/vjkIoWHiYdJkO0kxggcT3R/UIRx nLPERDFIUBZHBXtOkIZjQzkcFpyijwTn0V2Ena0IDg/XADpsJMIWKsIq4jwxNRPH0coaDi1O4K8F ffUbcY+grt3FMDFD3C5eEX0E9rk4WTwrOM9xgtWt+wUaZ9uizSLWtvUAPfJrJZoVydW6ZT69fauT k1/tNkRlipcrurMTG6sCLZfyiXEz3CD4lFCXtrYqGy4YJMIYGH4WG/nwxwq/EtyYJwhupLHiUrFI YAcJBga2aes/BFZVfacqf5u0VOWf5xVcJtoIBsCsXa2NpwR5vxQ9xWTBYPCewLYTDAAMXPcKJgAG KaxU+6qqr3LPync/jtQGgwjHYnBcTZwnGJiWhqE1/c15FNrSuh4YiPm0zABuW7YKDNXhuY/eF0+K iwWTbqExKYdNVYQJ8tFIUMg9Hg7AmorPF/8ncAK2FaWMY3YRuXwB7qN/iZXFXMFKUNgKikwSTOzk Zw2nhvu0qvoGKZ+JlGONEThRjCXXi7VEtIE6+oj9BW3IHqudthcKHAZsC/F3MUEwLnwq0CK7jzZT p4v2rV6QV1hfjHMzVI76mosjxJuip9hQ/EeEPa0IGmPvio8FemKMc2FoNlgcKmaKtiJrjDlhsxWh XTW1Cu0wRXyR35Fj4rx8T7whZomw/yqymnhNcO3FeXPdvCrCOLdWsVEibCaH6bgSed9OXqFNv+RX u6+aXPOvi5M5Id23izml8SvQcimf4guqf686PEZH1XWUOFowEGStlza4sR/KJHJTdRD3ikfFWQJn YlVxmmBAuUaQzuA0WvxAPCV6iWL1KblWL6lerP12EKeL7mKsYPBk4H5E/EmwDP5zcbDYU1TVvlL1 LdR+2B/EJNFHMCFxzueLtQUaMDiF86honRnn9iOB5oVW19dD1L+bIh/EhsNlqsBXOvq+AseFe2mU WF8U2opKmJ5P3ErhzQUFPtH28fk0HJd3xR0il08rFeDM4zQwsWJTxVzB9f6OyLalQtuUI52xpYv4 VGBdBRNxVfX1Uv7LAmcFmyKov5PgPhgjMNo8VXBOrcW2IqxCERwaZmLGNO6bU8XtIqyq9nE/l6qP /f8pGAOolzHlLnGuuFBsLxhvska/haFHC4HzVWhnKmElsZGYJe4TWWPsXVLDaVpN0AauKxwhrqmx gjGNfo7jbKL4nwVG2drbGTt10Q99jkxyzVonzXLqL4WJwmbNdfz8dm5RWx2lrR4JtlHvtktaNOuc 9N/2qOS6CehsswJLrMAvVcMrYoo4JV/blgr/mo8PVsgA+YD4n7hctBRYDxE3Q5qgPxuLs2MjH66l 8DLB4BuDcT4rHbi/FxuZ8DDFn8ls91ScgY2b8RbxKxF2pSLX5TdGKSxWXzOlv58vUxjsr4TYP5vH gLBArJtJpP17i33EPzPpayjOIMHAVqp9VdVHVbuKvxCRfV+MFycINB4uGIzuFGEMyg8LJhPStxHY CuJ6MU0wiO0ksK3FDeLX4r/iecE+TD5sfyb+kN+mHQPFOJG9HjiHCwU6PCuOEbRjgugswnB4DxH0 11DxP/Ge4NqgL7C7Rbc0Vjl5MBDTZs61XT6dNj8uSL9RrCiKGZNPsf25Fri+Obc7xOoCO1kwAd4q JovTRD/xpnhZ7CCaknEdcR9gHcSHgmuZ+3aIwOYLJmSMiXCOoH+w3cV2aeybP/Qj11Axu1iJV2Yy einO/dlJtBDnizsFdop4WnAtbSTeEnsJjGuQfOwIQbsZn3qJUvVdpbxRAuMcqftI0VpwjYYOOyr+ uUCPrgLnbmPRXrD/tQLjnvqtID1oqzhWqn1V1cd+q4l/CdpQaDhi3FthBypC39AX3Ftcy6HdMMVp W9gjivw0v0EbPs1sv6v4Zvk8gjfFLmJXwb2FcZ8xpmDZONvoT7sx7iGcKOxYcUsaS5IXFB6ejzOu fiTQnWP8W4RxfWTbPVXbO0dmLUOuH47VUTAOdBNcs71FX9EQ3sd2Gyvfj8vl+4y+ow/pS/qUvqWP 6et6NyZSLmImRJyjaWJjkb2BRmt7pugpthCviQMFtpv4Yxr75g/1jP9mc7EYg8P0xVIqnRKO8ZJ4 SMQA8mvFrxFh6yiCiNywE8SeIuyXiozLb/xTYbH61lI653e74JypeyWBnSTGCNrNAHiCwGLAqdyq /PuUAvJXFHRgGIPEq/mNUu2rqj52/Y0IbccpTv9gj4v9RJt8XEFqT+rvFYKB6ULBcTHO/y7B4Hik +FR0EfTrQsE+9POd4j7RWqABx1lTbC8+F2jyfZG9Hn6h7ZcFE9u+Yq7YUKApx8K4qElfQ5wonhO0 cRPxujhGYO+KrcT6YrY4QNBmJjj6f0XxkcD5qRBca3eLQiu1P8ecIfYWTJz0+QMCw1EgjzYfLBYJ 9NxJXCWinKJNwvroLOkztH9FDBEYOkV8vuIPCvp6pjhHhN2myKWxkQ9r4lCxy00Cx/5tMU10FxjX J8fF2ZkjLhFhmyvygWA/2rSnCCtV3wYq8KLgOqY++noFgf1IUBd5C8RJImygItwX7wv27ySwNwRj U5bnyZBV1b5S9VXuWTnW3aUNtD1f/FbcIq4Tq4uwAxV5RrwpaPt0sYPAhgn2CztIEdpPP3O9Xy7Y p7PgfuT+C6O+XUT2/uc6GZsvkI2TxPXRM593gEK0miTQcluBHSrQHP0+FGiAcQyuq7CLFcm2e6q2 d47MWoZ2qBqJO6b+517rK3qL7UQ3wT3RUTBeLBOH6rs6MBd1XOw4LUxi2RtotLavEGEMONfGRpGw h9LGF0knaUfBzZ41bm4GSPa7SswStGOEuEiENVNkkegqPhYxYCiaCjuBiKxUfd9R3gxxlGAgYEB5 WGCcH4MLehwvPhHHCjprisjardo4LZugeH/xqeiXTy/VvurqYwLYSqwhJuXraqGQ+toL9j9LYBuL r0RbNmTtBBPcSuJLUSHCxijCedOv1EWd2G7iP2mssu0P5uPbK8TxWjm/zX5MGthL4odprPIP18Pm 4mzxl8qk9JPpo/k45Qfk4wQnitCdAZzz5ZzuFmH0LTcLffCvSFS4imCSWyGTRrTU/mcqL+sYccNx I3KNXyauF2FcN3FenO+kyGhCIdfOdqJNiXOer3T6YC1R2AcldqlxMgNiN1FsQFxP6bSx0LieNxUt CzO0XV19qxXZh2NvIrinCo36NihMrGa7uvZVVx/9sY3oKppVcSzyqKuYDtndOC+0DCumQeQtScjE xrVSaFw7W4sOhRlLeZt+pU30IWMB1xnXe2/BeNNI3I3Gfxr0Vb7P6Dv6kL6kT+nbGjtU1d0wqrMs Y6IdJZ4QH4k/i6Gi0N7KJOBgFDoUZP9NbCmY+DmxVwQ2SDyWxor/4YZDHOxJ0UfsL+aKmNAVTQe3 hQqnCfIY2MO4QWMCLFXfNSrTRcSxOF8ma45BGxmMyEMTBqX+4kyRbYM20/ObTETGQPdXsZWg3U8L rFT75imvqvreVf7aAo2pG7jRSe8kzhC/EFiFoNwXAqPuIaK7YOB4VoShz/2Cdn8ovhLYbFFs0iBv qviESIFVaPv1TBrXD0bfoGdLcbC4WWAVgvSw/yqyamzkwwqF2TonaBt+J9B2ugjj3NBwTiQorBDF 9r9O6VkdOHf2i+Oja9gCRV7Lb6APN2VTsxk6YajO/lddgSXI/1z7QjF7p1ii0uivcPgLi9SmvkWq 5M3CivLbVdVXYpdaty/qw5F9OTaqCBm/uL+qM8aKrJbZ+6u6fWuSzz1V7FrhHpxYk4pc1gosTQWY VOrCmKTPFUwwJ4qjxUGi0PD6wpjgmJgK7UIlHC9+Lybn42yzQlHKOH7vTCYDwlTBRP62qBBhFYr8 R3wpGAzWF2EVijAZVlUfn2A3E2FTFcHxYXDpJTqLsCmK0AaOw7njiIV1VeRVgeNwq/hYoMnTIqxU +6qqj30fEv0Ejs5Qcb9oJW4T94gbREwchKuJFgKj3FHiM4FGtJN8WEeMEBiTxZIYx10zU8Heiq8r 3hJTxXfFnuJOgaEVxw/bRJGsVqTjDGXr3EjbPQTn8g8R50G4nsCpzlqp/QuPjbM6R8Sks6RaZNvQ FOJck3Obwon6HK2AFWg6CjSvo1M9XPVcJVhdeFCwKpB1HrSZ2qH6iwPRQRwmnhQYk1s4YC8q/oTg kxQTIXHAMSll85Rxk9g/X2BHhd0FbblP7CY2Fu3F6eIpgfF46BiBDky+OBLkVVXfGsp/TOB0tRAn iocFEwQ6XCEwVr6o7w7Bp6vnxE8EdoQgf5L4nthQnCqojzZCM1GqfVXVp93Sd5hwjFiF+qPYS9wo LhAcj3MIe0cRHL+++YQfKzwgn/aewv75dJydVwWOTFX2pTLbVVUgn0e/UHcbgRP0ZzFTYLeIiwQO 0wyB/V0cLdoKtKGvHxFZo8yeYn2BlvTF6mKs6C24zjCOO07kBM7RIQIrtT/pewvqxQ4Ujwr2t9Vc gSHaxQ5VzXXzHlagwSgwe/bs5KuvvkrbS8i2rTwFcC4mi6mCSfBxweOhXQUrEdhowcTGp/r3xWMC xwHDwZiWxr7500PR8d9sLhbDYZq+WErtXgJtrTpwunAc5ohLRNiPFKGtL4sF4iQRdpMi5L0taDfO G7aBwCFkH+p7QKADtrn4QLAfjsOeAhsimJgLoa6q2leqPu2WWnP9PUcw8eNYnCluFPeK3UXWcKA+ Fzh4tH1bgeGEfCxeE+SfJTD69d9prPLP1grQAasQH4o/ie3FWyIsez2spUSOhfboOFCEVSiCHkdG gsJ1BO14V3BN4eSE40baVgIbIXCI0flu0UJgQ8V8QR0cj+sLwznKXkul9h+pcuzP9T1FbCOwy8Tg NFb5h7q3y2/vpBCH1WYFrEDjUYCxlbG5o1hddBPc871FX7FcvXz0zjvvpHPLSiutlOvSpUuuffv2 uU033TR377331mk711577dzEiRPTOgcOHJhbd911c9OmTcvdc889ufXXXz83cuTIOj1eXVRGX+X7 jL6jD+lL+pS+pY/p62ViHHxLQWOKGQ7VzwUOBpPp0jBOfhMRE232GAi0QTYhE19P8ZUy2xGtrj7E LyY49a0WlWRCJnceGbbMpJUTLdW+cuprpgN0FTgAbao4GP1XrF/YB4dplSr2LcxqpYRwJAvzCrfX VQLnUY7F+RZrZ3Z/Vkc7ZRPycc4BHTjXqqzU/mtqp81Eue2t6hjOswJWoGEqwJjPGNKgHKr58+en PohWi3JDhgxJnauFCxfWhV+S1vH222/n4hgdOnTIvfnmm2n6gAEDckOHDq2z49RlRerD5dahqu7W CIequnLOtwJWwApYASuwvCrQoB0qHJIxY8Z87VC9/vrruf79++eGDx+e69mzZ+qvPPDAA2mcVaYf /vCHuY8++ihNv/TSS3NXXXVVrm/fvrm11lord8QRR+TmzZuX5h100EG5SZMmpeWbN2+e23HHHXOX XHJJbtVVV8117do1d9NNN6Xllqc/usAarEN1qBq/w/J6h7hdVsAKWAErYAXKUKBBOlTXXXdd7oYb bsjhFG2xxRa5Cy64IPVtnn/++RwrSr17987hSC1atCjNv++++3Iffvhh6iCdffbZadmTTjop16lT p9ztt9+ee/zxx3MVFRW5UaNGpXnxyI9HjG3bts0999xzuenTp+cOOeSQ3HnnnZebMWPG8uRLpW1R X9epQ1XTR09lXGsli9xZMscZVsAKWAErYAWswFJT4JFHHkm0cpRoRSmZNWtW8tJLLyVyntLjffHF F8ltt92WrLzyysncuXOTESNGJD169EgWLFiQbLjhhskzzzzzdbu0KpUcdthh6fbBBx+cvPFGvCZd WUSrWgn/O1rOVrLKKqskHTt2TLRKlXTu3PnrOhprpD4dqsaqoc/LClgBK2AFrMByrYAeuSWtW1e+ PorTtO222ybjx49PHR6cH5wprF27dsmECROS4447Lvnss88SPdpLHaI4ObbDVlhhhdQBi+2mHhZ7 obqpa+LztwJWwApYASvQaBXQN/3SFaSXX375W+eIk3XhhRcm999/f/L+++8ngwYNSlecoiCrXLbi CliZ4ro41QpYAStgBaxAo1Fgzpw56WqS3mtKHSYcp/322+9b58cjvG222Sbp1q1b8uWXXya33HIL vwPxrXJO+LYCdqi+rYlTrIAVsAJWwAo0KgX0G1QJj+jWWWedZPTo0cmNN96Yvh9VeJKHH354MnXq 1KR79+7Jlltumb5L9eKLLyb6PanCot4uUIDfKLJZAStgBayAFbAC5SnAQgTvH/Mbfe1FB7Gi4K1r XkS6rTGs6EyePDnRD3ImLVu2TF9i5/0rfXtPp9d4jJfnZYeLT8RMMUvMFnMFP+T8pah8c1+R6swv pVenkPOtgBWwAlbACjQxBXjkF7biiviLtuoU8CO/6hRyvhWwAlbAClgBK2AFqlHADlU1AjnbClgB K2AFrIAVsALVKWCHqjqFnG8FrIAVsAJWwApYgWoUsENVjUDOtgJWwApYASvQ2BQ46qij0h/61L+d Sb/9p38dk+hfy6Q/5sm57rLLLgl5/OAn71Dxg56nnHJKon+unP7a+iabbJL+RlVWl3322Sfp169f NslxK2AFrIAVsAJWwAoUVYCFCH5yvKNYXfD29nait+grlrv/WVesQfzT4zPOOOPrLP7X3kYbbZS7 7LLL0rSdd955sX9orH9Vk9M3/XIPPfRQmq9/R5Nr1apVbuzYsen2tddem1tzzTVzn3zySbrdEP7Q V/k+o+/oQ/qSPqVv6eMaLTrVqLAqt1kBK2AFrIAVsAKNTAH+1x6rS3KQip7ZZpttlv5vvvxPDSRy uJJTTz01GTBgQPLKK6+kq1fXX399wu9dNVXzzyY01Z73eVsBK2AFrIAVyCvAv6HhV9F57BfGr6nz a+nz589PHn300fRHQXv3ZjGn0s4999z0X9TgXPXv37/oL69H2aYQeoWqKfSyz9EKWAErYAWsQIEC w4YNS/9PH6tO22+/fbLeeust9g7UxIkTk4cffjgZM2ZMMmXKlGTmzJkJP/gZxo997rXXXum/tOnT p08kO7QCVsAKWAErYAWsQLUKNJp3qLQalfv4449T5s2bt9hrT4XvUJFJ+RNOOOHrcnK4cu3atcsd d9xxuYqKipz+X+DXeQ0hop72O1TVXu4uYAWsgBWwAlbACjUiw0MAAAaYSURBVFSpgJyh9Ft8fJOv nH8rs/nmmyc8GsT4tt9Pf/rT5Pjjj09GjBiRdOrUKRk8eHCVx2vsmX7k19h72OdnBayAFbACVqAW CvDu1Ny5cxOtPCV33XVXom8Afv2e1OWXX55Mnz49Oe+885IWLVokV199dTJ8+PDkhRdeqMWRGscu dqgaRz/6LKyAFbACVsAK1KkCxx57bPobVfwe1aBBg5K99947Ofnkk9P3qFiNuvLKK9N8Drrbbrsl Rx99dKLHf+nqVZ02pIFUlv6r5QbSVjfTClgBK2AFrMCyVoCFCL4h30a0Fx0E/z24s1hZ3Kb3hxTY lncF8j8Bcbja+YmYKWaJ2WKumC++FItEWeYVqrJkciErYAWsgBWwAlbACpRWwA5VaW2cYwWsgBWw AlbACliBshSwQ1WWTC5kBayAFbACVsAKWIHSCtihKq2Nc6yAFbACVsAKWAErUJYCdqjKksmFrIAV sAJWwApYAStQWgE7VKW1cY4VsAJWwApYAStgBcpSwA5VWTK5kBWwAlbAClgBK2AFSitgh6q0Ns6x AlbAClgBK2AFrEBZCtihKksmF7ICVsAKWAErYAWsQGkF7FCV1sY5VsAKWAErYAWsgBUoSwE7VGXJ 5EJWwApYAStgBayAFSitgB2q0to4xwpYAStgBayAFbACZSlgh6osmVzIClgBK2AFrIAVsAKlFbBD VVob51gBK2AFrIAVsAJWoCwF7FCVJZMLWQErYAWsgBWwAlagtAJ2qEpr4xwrYAWsgBWwAlbACpSl gB2qsmRyIStgBayAFbACVsAKlFbADlVpbZxjBayAFbACVsAKWIGyFLBDVZZMLmQFrIAVsAJWwApY gdIK2KEqrY1zrIAVsAJWwApYAStQlgJ2qMqSyYWsgBWwAlbAClgBK1BaATtUpbVxjhWwAlbACliB QgVySijFosLC3l7uFaDPSvUn6WWbHaqypXJBK2AFrIAVsAKLKZCdiJmY7VAtJk+D2Ih+y/ZlrRpu h6pWsnknK2AFrIAVaOIKZCfgmJS/auKaNMTTp8+i/7J9WuNzaVnjPbyDFbACVsAKWAErEAowGTMp w5ci10ym0Lb8K4ADRZ9F/9GXtTY7VLWWzjtaAStgBaxAE1aAyThWNpiQF+b5gcJOYkWxgmgv2opW gjnXT4YkQj0afYTTRP98IeaKOWKW+ExEv9GH0Z/0bY3NDlWNJfMOVsAKWAEr0MQViEdDTMCxMsWk PV8wabcWLQRGmQUi0uxQoUr9WfQRfQDzBA4VIX1Fn9F3sVJF+ehfRcs3O1Tla+WSVsAKWAErYAVi siWMyRqnismayZmJOpypSMeZYoWKdD8OlAj1aPQT/cBKFH2EE5V1qugz0ikDWYeKfcs2O1RlS+WC VsAKWAErYAW+ViDrUDEh4ywxp8a8Gs4UkzcOFemsTnmFSiLUo+EgAStQ9FPWqeLxX6xShVMVDpWy ambR8TXby6WtgBWwAlbACjRdBbLOFCsfOEk4VOEsxeM/HKlwpiI/yijLVg8KhEOFg5t1quLxLA4v zlThu1Q1Wp3iPOxQoYLNClgBK2AFrEDNFCh0quJRXqyGMGHzmC8e9eFIQZRT1FYPCkQ/0S84VeE4 EcbjPkK2s4/8tFkzs0NVM71c2gpYAStgBaxATNI4R0zC4SSRzjbEI0DCWJ2iXJRV1FYPCtAn0V/R N/ECenZlKtJiRYt9amR2qGoklwtbAStgBayAFUgnaBwjJt+wmLRjhSrrSMXKlB2qUKv+wnCosv0T jhVhrExFWvSpHar66yMfyQpYAStgBZqwAjHhZidg4oADhUOFA5V1prTpFSpEqEeLfiIE+ocQB4p4 hNF3UU5ZNTMvPdZML5e2AlbAClgBKxAKZFecwnGKMJwpymbLxb4O61eBrKMUTlXWwSINy5arTCnz rx2qMoVyMStgBayAFbACJRTIOkyF8djF820osWxCHKWwiGedp2w8ytUodAfXSC4XtgJWwApYAStQ rQLF5tZiadVW5AJ1pkA4UdkKi6Vl8x23AlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAEr YAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAV sAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAK WAErYAWsgBWwAlbACliBxq3A/wf7XtEbk5hacAAAAABJRU5ErkJggg== ------_=_NextPart_001_01CA9DCB.F9840206-- From pkyzivat@cisco.com Mon Jan 25 06:40:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873283A6838 for ; Mon, 25 Jan 2010 06:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=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 wd5Sjt2mJUAM for ; Mon, 25 Jan 2010 06:40:46 -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 3CBF63A6897 for ; Mon, 25 Jan 2010 06:40:46 -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: ApoEAN07XUtAZnwM/2dsb2JhbADEB5VLgjCCCwQ X-IronPort-AV: E=Sophos;i="4.49,339,1262563200"; d="scan'208";a="81870462" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2010 14:40:51 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0PEepSj021196; Mon, 25 Jan 2010 14:40:51 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 08:40:51 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 08:40:51 -0600 Message-ID: <4B5DAD72.4050806@cisco.com> Date: Mon, 25 Jan 2010 09:40:50 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 14:40:51.0582 (UTC) FILETIME=[645769E0:01CA9DCC] Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:40:48 -0000 inline... Elwell, John wrote: > Adam, > > Thanks for going to the trouble of explaining things in this clear way. See below. > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 22 January 2010 17:16 >> To: Dean Willis >> Cc: Elwell, John; martini@ietf.org; Hadriel Kaplan >> Subject: Re: [martini] Requirements - rev1 >> >> "On 1/22/10 1:24 AM, Dean Willis wrote: >> >> Consider for example the debate we're currently having >> about whether the SSP does "contact routing" and replaces the >> r-URI with a registered contact, or does "domain routing" and >> just pushes the registered route onto the route stack >> (really, it MUST do the latter, but REGISTER implies the >> former, which makes it something of a hack). >> >> >> >> I'm not sure it must do the latter. I think there are some >> people here whose use cases will work if you do it that way, >> but I think a careful examination of everyone's position will >> show that it simply won't work for others'. >> >> On the other hand, the "contact routing" approach, as far as >> I can tell, will work for all the use cases described so far, >> as long as we have the ability to define a mapping from AOR >> to contact URI in some sensible fashion. The martini-up draft >> gives an existence proof of such a mechanism -- and the >> mechanism is hardly NOTIFY-specific. It could be used just as >> sensibly with REGISTER. >> >> So, let's take a quick look at the "contact routing" approach >> versus the "domain routing" approach. I hope you'll excuse >> that I'm stepping slightly outside IETF norms to convey these >> concepts clearly: to save the confusion among "example.com," >> "example.org," and "example.net," I'm going to use dead >> companies in my example; I'm also going to use inline images >> for my diagrams. >> >> Ignoring how the information gets there in the first place, >> the "domain routing" approach looks sensible at first blush >> for this kind of application. Here is an SSP and two of its >> customers. Through some non-DNS mechanism, the SSP knows to >> route the domain "pan-am.com" to the Pan Am PBX, and to route >> the domain "braniff.com" to the Braniff PBX: >> >> >> >> Great. Aside from the somewhat nonstandard determination of >> the next-hop server at the SSP, this is pretty normal handling. >> >> That said, MARTINI has a special relationship with phone >> numbers. They're in our charter: " The solution will support >> AoRs with E.164 >> addresses at a minimum, although support for other classes of >> AoRs may be included." So, let's explore what that ends up meaning. >> >> As long as we expect some external party (not the SSP) to >> determine what domain each E.164 number belongs to, then >> everything works the same as my previous example: >> >> >> >> And, if that's good enough, then great. But I'm willing to >> bet that at least one person working in this space looks at >> that diagram and says, "No! That's not what I meant! I want >> the SSP to handle the number mapping." >> >> Now, if we stick with the "the SSP does not rewrite the URI" >> approach that Keith and John are rather adamant about, the >> only thing we can really do in terms of "these numbers go >> here, those numbers go there" looks something like this: > [JRE] Although I may not have made myself clear, what I really am adamant about is preserving the identity of the target user in the Request-URI. So if the domain part is changed, but the user-info part is retained, that would be satisfactory. How have you preserved the identity of the target if you have retained the user-part but replaced the domain part? That may work for e.164 numbers, but only them. john.elwell is unique in siemens-enterprise.com, but its quite likely that verizon.net or comcast.net has a john.elwell that is not you. (I can't use my own name for examples like this.) It works for e.164 numbers because they are globally unique in their own right, and by convention when used with domain names. >> I suspect most people can tell that's wrong by simple >> inspection. What I'm willing to bet people are expecting is >> something more like this: >> >> >> >> But that's most certainly not the "domain routing" model Dean >> is talking about. In fact, it's pretty much the "contact >> routing" model straight up, with an AOR to Contact mapping of >> "sip:+15005550100@centricvoice.com => >> sip:+15005550100@pan-am.com" (and a similar one for +15005550200). >> >> Okay, great. So the "contact routing" approach works fine for >> the later cases. But what about the people who want to >> register entire domains? That's the neat thing about the >> "contact routing" approach -- if done correctly, it works >> just fine for those cases, too. Going back to the first >> example; if we perform normal "contact routing" -- URI >> rewriting and all -- and have the PBXes register their IP >> addresses as the mapped contacts, everything works fine: >> >> >> >> This is great! Now we're using REGISTER to put an AOR to >> Contact mapping in place (like it always has) instead of >> using it to install rules to override normal RFC3263 >> handling. Best of all, we're not saying "ignore DNS and use >> this alternate mechanism for turning names into addresses" >> like we have to with the "domain routing" approach. > [JRE] This would seem reasonable. The point is, if the PBX registers as its contact address pbx123@10.15.2.4, then inbound INVITE requests would not contain that same value in the Request-URI, but would contain something like dsmith@10.15.2.4. The identity of the target is retained. So I think we are in agreement. This could probably be made to work. But it requires new conventions about the form of contact URIs, conventions we have never had before. The rule has always been that the registering device can use whatever contact URI it wishes, as long as it routes to itself, and in particular it can use the user-info portion of that URI to encode arbitrary information that may be helpful to itself. If an special convention is required for this new mechanism, then we need to be very explicit about it. Thanks, Paul > John > > >> So, Dean: can you explain what breaks if we use "contact >> routing" for all the use cases described so far? >> >> /a >> >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Mon Jan 25 07:07:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2503A6817 for ; Mon, 25 Jan 2010 07:07:27 -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, 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 vJv7E55dHJak for ; Mon, 25 Jan 2010 07:07:25 -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 38B853A635F for ; Mon, 25 Jan 2010 07:07:24 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PF7QZl004577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 09:07:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DB3AE.40107@nostrum.com> Date: Mon, 25 Jan 2010 09:07:26 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> In-Reply-To: <4B5DAD72.4050806@cisco.com> Content-Type: multipart/alternative; boundary="------------070508070505000702020600" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 15:07:27 -0000 This is a multi-part message in MIME format. --------------070508070505000702020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/25/10 8:40 AM, Paul Kyzivat wrote: > inline... > > Elwell, John wrote: >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] Sent: 22 January 2010 17:16 >>> >>> This is great! Now we're using REGISTER to put an AOR to Contact >>> mapping in place (like it always has) instead of using it to install >>> rules to override normal RFC3263 handling. Best of all, we're not >>> saying "ignore DNS and use this alternate mechanism for turning >>> names into addresses" like we have to with the "domain routing" >>> approach. >> [JRE] This would seem reasonable. The point is, if the PBX registers >> as its contact address pbx123@10.15.2.4, then inbound INVITE requests >> would not contain that same value in the Request-URI, but would >> contain something like dsmith@10.15.2.4. The identity of the target >> is retained. So I think we are in agreement. > > This could probably be made to work. > > But it requires new conventions about the form of contact URIs, > conventions we have never had before. > > The rule has always been that the registering device can use whatever > contact URI it wishes, as long as it routes to itself, and in > particular it can use the user-info portion of that URI to encode > arbitrary information that may be helpful to itself. > > If an special convention is required for this new mechanism, then we > need to be very explicit about it. I'd like to be explicit about it at a protocol level. I'll reiterate that the AOR to Contact mapping model I propose in draft-roach-martini-up is *not* specific to the use of PUBLISH. Using a similar mechanism in REGISTER -- whether in the header or in the body -- would achieve the same goals. More importantly, it would address Dean's concern: > What happens when the PBX supports two domains, and there might be > user-name overlaps between the domains? If both > dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are contact-routed > by the SSP into dwillis@10.1.2.3, we have something of a mess. Because, in this case, the registration could look something like this (using the syntax from martini-up): 1 full /sip:(.*)@eng.pan-am.com/sip:\1-eng@10.2.14.7/ /sip:(.*)@mktg.pan-am.com/sip:\1-mktg@10.2.14.7/ That's very explicit. It's not even a convention; it's a protocol. /a --------------070508070505000702020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/25/10 8:40 AM, Paul Kyzivat wrote:
inline...

Elwell, John wrote:

-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com] Sent: 22 January 2010 17:16

This is great! Now we're using REGISTER to put an AOR to Contact mapping in place (like it always has) instead of using it to install rules to override normal RFC3263 handling. Best of all, we're not saying "ignore DNS and use this alternate mechanism for turning names into addresses" like we have to with the "domain routing" approach.
[JRE] This would seem reasonable. The point is, if the PBX registers as its contact address pbx123@10.15.2.4, then inbound INVITE requests would not contain that same value in the Request-URI, but would contain something like dsmith@10.15.2.4. The identity of the target is retained. So I think we are in agreement.

This could probably be made to work.

But it requires new conventions about the form of contact URIs,
conventions we have never had before.

The rule has always been that the registering device can use whatever contact URI it wishes, as long as it routes to itself, and in particular it can use the user-info portion of that URI to encode arbitrary information that may be helpful to itself.

If an special convention is required for this new mechanism, then we need to be very explicit about it.

I'd like to be explicit about it at a protocol level.

I'll reiterate that the AOR to Contact mapping model I propose in draft-roach-martini-up is *not* specific to the use of PUBLISH. Using a similar mechanism in REGISTER -- whether in the header or in the body -- would achieve the same goals. More importantly, it would address Dean's concern:

What happens when the PBX supports two domains, and there might be user-name overlaps between the domains? If both dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are contact-routed by the SSP into dwillis@10.1.2.3, we have something of a mess.

Because, in this case, the registration could look something like this (using the syntax from martini-up):

1 full
/sip:(.*)@eng.pan-am.com/sip:\1-eng@10.2.14.7/
/sip:(.*)@mktg.pan-am.com/sip:\1-mktg@10.2.14.7/

That's very explicit. It's not even a convention; it's a protocol.

/a

--------------070508070505000702020600-- From spencer@wonderhamster.org Mon Jan 25 07:19:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC6A3A68D9 for ; Mon, 25 Jan 2010 07:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_46=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 fG812nqnIdpI for ; Mon, 25 Jan 2010 07:19:00 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 565E93A635F for ; Mon, 25 Jan 2010 07:19:00 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Mcm7t-1NHcqf1r1t-00I842; Mon, 25 Jan 2010 10:19:01 -0500 Message-ID: From: "Spencer Dawkins" To: "Paul Kyzivat" , "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> Date: Mon, 25 Jan 2010 09:18:51 -0600 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/1PtsrRL4w/U8N6fXFptQXchnYNYFNS6AKpuh gg4IOq7c5/EpGw+FzydDFG1OAOjQ3HxieaFuA1kUheECSAGTyV h/56Av9V670FW1fW5QejZulDFgUaiRR/9QnbN8f2ss= Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 15:19:01 -0000 Thanks to Adam for his post, from me as well. One question inline... Spencer >>> Now, if we stick with the "the SSP does not rewrite the URI" approach >>> that Keith and John are rather adamant about, the only thing we can >>> really do in terms of "these numbers go here, those numbers go there" >>> looks something like this: >> [JRE] Although I may not have made myself clear, what I really am adamant >> about is preserving the identity of the target user in the Request-URI. >> So if the domain part is changed, but the user-info part is retained, >> that would be satisfactory. > > How have you preserved the identity of the target if you have retained the > user-part but replaced the domain part? > > That may work for e.164 numbers, but only them. > > john.elwell is unique in siemens-enterprise.com, but its quite likely that > verizon.net or comcast.net has a john.elwell that is not you. > > (I can't use my own name for examples like this.) > > It works for e.164 numbers because they are globally unique in their own > right, and by convention when used with domain names. What I've been hearing consistently for a year is that, for the people who want this mass registration mechanism, "telephone numbers" (and I'm willing to stipulate "E.164 numbers") are what they are currently dealing with, and what they expect to be dealing with for a while. I don't think any of the people I've been hearing would object to an E.164-only mechanism, which I'm understanding Paul to be saying, would work. How would we know that the user part is an E.164 number, unambiguously, so that we don't have to reopen the discussion about interpreting user parts (which doesn't sound like a short conversation)? Restrict to "tel:" URI? "user=phone" (and how would the caller know to do this)? is there a good answer? If there is, great. If there's not, can we decide that quickly? Thanks, Spencer From bruno.chatras@orange-ftgroup.com Mon Jan 25 07:38:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D293A635F for ; Mon, 25 Jan 2010 07:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 UfQAu1jeLWO2 for ; Mon, 25 Jan 2010 07:38:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id DEBC43A6816 for ; Mon, 25 Jan 2010 07:38:56 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 771AE134283; Mon, 25 Jan 2010 16:39:00 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5AC2635C04E; Mon, 25 Jan 2010 16:39:00 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 16:39: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: Mon, 25 Jan 2010 16:38:57 +0100 Message-ID: <18227_1264433940_4B5DBB14_18227_357_1_9ECCF01B52E7AB408A7EB853526421410101A9F0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B5DAD72.4050806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqdzGf5SeR8aI8PRW+8IOfFBN+/PAABoQ5Q References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> From: To: , X-OriginalArrivalTime: 25 Jan 2010 15:39:00.0753 (UTC) FILETIME=[840CA810:01CA9DD4] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.18.63320 Cc: HKaplan@acmepacket.com, martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 15:38:58 -0000 If my memory is correct a solution where only the user part was preserved w= as proposed to ETSI and 3GPP two years ago and rejected. One of the reason= why this solution was rejected is that it did not allow for the case where= one PBX is associated to two domain names (e.g. one domain name representi= ng a company and another one representing a brand owned by this company) an= d UserX@DomainA is different from UserX@DomainB.=20 BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Paul Kyzivat > Envoy=E9 : lundi 25 janvier 2010 15:41 > =C0 : Elwell, John > Cc : martini@ietf.org; Hadriel Kaplan > Objet : Re: [martini] Requirements - rev1 >=20 > inline... >=20 > Elwell, John wrote: > > Adam, > >=20 > > Thanks for going to the trouble of explaining things in=20 > this clear way. See below. > >=20 > >> -----Original Message----- > >> From: Adam Roach [mailto:adam@nostrum.com] > >> Sent: 22 January 2010 17:16 > >> To: Dean Willis > >> Cc: Elwell, John; martini@ietf.org; Hadriel Kaplan > >> Subject: Re: [martini] Requirements - rev1 > >> > >> "On 1/22/10 1:24 AM, Dean Willis wrote:=20 > >> > >> Consider for example the debate we're currently having=20 > about whether=20 > >> the SSP does "contact routing" and replaces the r-URI with a=20 > >> registered contact, or does "domain routing" and just pushes the=20 > >> registered route onto the route stack (really, it MUST do=20 > the latter,=20 > >> but REGISTER implies the former, which makes it something=20 > of a hack). > >>=20=09 > >> > >> > >> I'm not sure it must do the latter. I think there are some people=20 > >> here whose use cases will work if you do it that way, but=20 > I think a=20 > >> careful examination of everyone's position will show that=20 > it simply=20 > >> won't work for others'. > >> > >> On the other hand, the "contact routing" approach, as far as I can=20 > >> tell, will work for all the use cases described so far, as=20 > long as we=20 > >> have the ability to define a mapping from AOR to contact=20 > URI in some=20 > >> sensible fashion. The martini-up draft gives an existence proof of=20 > >> such a mechanism -- and the mechanism is hardly=20 > NOTIFY-specific. It=20 > >> could be used just as sensibly with REGISTER. > >> > >> So, let's take a quick look at the "contact routing"=20 > approach versus=20 > >> the "domain routing" approach. I hope you'll excuse that=20 > I'm stepping=20 > >> slightly outside IETF norms to convey these concepts=20 > clearly: to save=20 > >> the confusion among "example.com," > >> "example.org," and "example.net," I'm going to use dead=20 > companies in=20 > >> my example; I'm also going to use inline images for my diagrams. > >> > >> Ignoring how the information gets there in the first place, the=20 > >> "domain routing" approach looks sensible at first blush=20 > for this kind=20 > >> of application. Here is an SSP and two of its customers.=20 > Through some=20 > >> non-DNS mechanism, the SSP knows to route the domain=20 > "pan-am.com" to=20 > >> the Pan Am PBX, and to route the domain "braniff.com" to=20 > the Braniff=20 > >> PBX: > >> > >> > >> > >> Great. Aside from the somewhat nonstandard determination of the=20 > >> next-hop server at the SSP, this is pretty normal handling. > >> > >> That said, MARTINI has a special relationship with phone numbers.=20 > >> They're in our charter: " The solution will support AoRs=20 > with E.164=20 > >> addresses at a minimum, although support for other classes of AoRs=20 > >> may be included." So, let's explore what that ends up meaning. > >> > >> As long as we expect some external party (not the SSP) to=20 > determine=20 > >> what domain each E.164 number belongs to, then everything=20 > works the=20 > >> same as my previous example: > >> > >> > >> > >> And, if that's good enough, then great. But I'm willing to=20 > bet that=20 > >> at least one person working in this space looks at that=20 > diagram and=20 > >> says, "No! That's not what I meant! I want the SSP to handle the=20 > >> number mapping." > >> > >> Now, if we stick with the "the SSP does not rewrite the URI"=20 > >> approach that Keith and John are rather adamant about, the=20 > only thing=20 > >> we can really do in terms of "these numbers go here, those=20 > numbers go=20 > >> there" looks something like this: > > [JRE] Although I may not have made myself clear, what I=20 > really am adamant about is preserving the identity of the=20 > target user in the Request-URI. So if the domain part is=20 > changed, but the user-info part is retained, that would be=20 > satisfactory. >=20 > How have you preserved the identity of the target if you have=20 > retained the user-part but replaced the domain part? >=20 > That may work for e.164 numbers, but only them. >=20 > john.elwell is unique in siemens-enterprise.com, but its=20 > quite likely that verizon.net or comcast.net has a=20 > john.elwell that is not you. >=20 > (I can't use my own name for examples like this.) >=20 > It works for e.164 numbers because they are globally unique=20 > in their own right, and by convention when used with domain names. >=20 > >> I suspect most people can tell that's wrong by simple inspection.=20 > >> What I'm willing to bet people are expecting is something=20 > more like=20 > >> this: > >> > >> > >> > >> But that's most certainly not the "domain routing" model Dean is=20 > >> talking about. In fact, it's pretty much the "contact=20 > routing" model=20 > >> straight up, with an AOR to Contact mapping of=20 > >> "sip:+15005550100@centricvoice.com =3D> sip:+15005550100@pan-am.com"= =20 > >> (and a similar one for +15005550200). > >> > >> Okay, great. So the "contact routing" approach works fine for the=20 > >> later cases. But what about the people who want to register entire=20 > >> domains? That's the neat thing about the "contact routing"=20 > approach=20 > >> -- if done correctly, it works just fine for those cases,=20 > too. Going=20 > >> back to the first example; if we perform normal "contact=20 > routing" --=20 > >> URI rewriting and all -- and have the PBXes register their IP=20 > >> addresses as the mapped contacts, everything works fine: > >> > >> > >> > >> This is great! Now we're using REGISTER to put an AOR to Contact=20 > >> mapping in place (like it always has) instead of using it=20 > to install=20 > >> rules to override normal RFC3263 handling. Best of all, we're not=20 > >> saying "ignore DNS and use this alternate mechanism for=20 > turning names=20 > >> into addresses" > >> like we have to with the "domain routing" approach. > > [JRE] This would seem reasonable. The point is, if the PBX=20 > registers as its contact address pbx123@10.15.2.4, then=20 > inbound INVITE requests would not contain that same value in=20 > the Request-URI, but would contain something like=20 > dsmith@10.15.2.4. The identity of the target is retained. So=20 > I think we are in agreement. >=20 > This could probably be made to work. >=20 > But it requires new conventions about the form of contact URIs, > conventions we have never had before. >=20 > The rule has always been that the registering device can use whatever=20 > contact URI it wishes, as long as it routes to itself, and in=20 > particular=20 > it can use the user-info portion of that URI to encode arbitrary=20 > information that may be helpful to itself. >=20 > If an special convention is required for this new mechanism, then we=20 > need to be very explicit about it. >=20 > Thanks, > Paul >=20 > > John > >=20 > >=20 > >> So, Dean: can you explain what breaks if we use "contact=20 > >> routing" for all the use cases described so far? > >> > >> /a > >> > >> > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Mon Jan 25 08:11:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07DB628C0E3 for ; Mon, 25 Jan 2010 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 TistcZVKGmEX for ; Mon, 25 Jan 2010 08:11:21 -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 27A173A6857 for ; Mon, 25 Jan 2010 08:11:18 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PGBK7W010061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 10:11:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DC2A8.6030803@nostrum.com> Date: Mon, 25 Jan 2010 10:11:20 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000408030706030408070108" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:11:23 -0000 This is a multi-part message in MIME format. --------------000408030706030408070108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/22/10 11:58 PM, Dean Willis wrote: >> >> >> >> I suspect most people can tell that's wrong by simple inspection. >> What I'm willing to bet people are expecting is something more like >> this: >> >> >> >> But that's most certainly not the "domain routing" model Dean is >> talking about. In fact, it's pretty much the "contact routing" model >> straight up, with an AOR to Contact mapping of >> "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" >> (and a similar one for +15005550200). > > No, it's neither: it's table-driven retargeting. You're transforming a > request for one domain into a request for another domain, based > strictly on the "user part" of the original request. This is ignoring > the domain-part of the registered AOR. No, that's not what I'm trying to show here. The user portion certainly could stay the same, but that would be local policy, not built-in mechanism. My example would be the same thing if the user portion were remapped via some transformation. For example, the diagram I included originally would be the result of a transformation like this: /sip:(+150055501..)@centricvoice.com/sip:\1@pan-am.com/ But the Pan Am PBX could just as easily have requested a transformation like this: /sip:+1500555(01..)@centricvoice.com/sip:extension-\1@pan-am.com/ And it would all work just fine: > So it's not contact routing; remember, contact-routing takes as its > input an AOR. It looks this AOR up in a table populated by storing > AORs (including user and domain parts) received in REGISTER requests, > returns the Contact matching the AOR, and replaces the request URI > with the Contact before proxying the request on. I don't know where you got the impression that I was proposing to ignore the domain portion. If the "CentricVoice (SSP)" entity wanted to treat incoming requests with different domain names as different, it certainly should be able to. > By matching only on the user-part of the AOR, you;re doings > something that isn't quite contact routing. I never proposed that you should be doing this. ---------------------------------------------------------------------- *WARNING* *WARNING* *WARNING*!!! If you are not Dean, the following example and my response may be very confusing. Dean is discussing some valid but highly esoteric and unlikely scenarios. In particular, he is using user names that look exactly like E.164 numbers, but which actually are *NOT* taken from the E.164 numbering space. > What happens when "+15005550100" is a valid user-part on both the > pan-am.com and braniff.com domains? Then you're going to have to use a different AOR on the CentricVoice service. Both pan-am.com and braniff.com could define their own remapping rules that, when applied, transform incoming requests at centricvoice.com into "sip:+15005550100@pan-am.com" and "sip:+15005550100@braniff.com" respectively. The Pan Am PBX could, for example, register for: /sip:pan-am-(....)@centricvoice.com/sip:+1500555\1@pan-am.com/ While the Braniff PBX might register for: /sip:braniff-(....)@centricvoice.com/sip:+1500555\1@braniff.com/ ---------------------------------------------------------------------- >> Okay, great. So the "contact routing" approach works fine for the >> later cases. But what about the people who want to register entire >> domains? That's the neat thing about the "contact routing" approach >> -- if done correctly, it works just fine for those cases, too. Going >> back to the first example; if we perform normal "contact routing" -- >> URI rewriting and all -- and have the PBXes register their IP >> addresses as the mapped contacts, everything works fine: >> >> >> >> This is great! Now we're using REGISTER to put an AOR to Contact >> mapping in place (like it always has) instead of using it to install >> rules to override normal RFC3263 handling. Best of all, we're not >> saying "ignore DNS and use this alternate mechanism for turning names >> into addresses" like we have to with the "domain routing" approach. > > > Nope. What happens when the PBX supports two domains, and there might > be user-name overlaps between the domains? If both > dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are contact-routed > by the SSP into dwillis@10.1.2.3, we have something of a mess. This > requires sending the untransformed r-URI to the PBX. No, it requires having a mapping that allows the PBX to properly correlate the r-URI with the user. You propose that this must be a unity mapping. But we have a clear existence proof that this works with arbitrary mapping, because THAT'S HOW REGISTER WORKS TODAY. The UA installs an arbitrary mapping from AOR to Contact address. And many, if not most, modern UAs can handle multiple registrations and figure out (based on the r-URI) which user an incoming INVITE belongs to. You can get rid of most of the problems we've identified by allowing a programmatic mapping from AOR to Contact value. Your example, for instance, can be solved by having different mappings for each of those users. I already showed this in an earlier message, but I'd like to reiterate it here, with some alternatives. You can trivially address the "@mktg..." versus "@eng..." issue with mappings like this: 1 full /sip:(.*)@eng\.pan-am\.com/sip:\1-eng@10.1.2.3/ /sip:(.*)@mktg\.pan-am\.com/sip:\1-mktg@10.1.2.3/ Alternately (since you raised UUCP and email), you could use a syntax like this: 1 full /sip:(.*)@(eng\.pan-am\.com)/sip:\1%40\2@10.1.2.3/ /sip:(.*)@(mktg\.pan-am\.com)/sip:\1%40\2@10.1.2.3/ > Also, what happens to security assumptions around the AOR-contact > mapping as assumed in draft-ietf-sip-outbound? We end up with traffic > for multiple users occurring over one flow, and that leads to the > attack-model we panned the early connection-reuse drafts for allowing. Ah, now you're getting into the arguments that REGISTER is the wrong tool (or that REGISTER needs to have a Proxy-Require) for this application. And we're in complete agreement there. Any use of REGISTER for multiple AORs that correspond to multiple humans[*] is going to be broken from a security perspective. I raised this issue at the microphone in Hiroshima, and I jumped up and down on it a lot on the mailing list in early January (e.g., "You are changing a fundamental property of a core SIP construct -- the operation no longer applies to just the user indicated in the 'To' header field; it applies to myriad disparate users. Intermediaries assuming it means what RFC 3261 says it means will be mislead, and make potentially incorrect policy decisions as a consequence"). Believe me, this issue is near and dear to me. If you see me proposing something that you think means I don't care about this, then you're reading it wrong. /a [*] I'm avoiding the use of the word "user," since that word has been hijacked to mean something bizarre in this conversation. --------------000408030706030408070108 Content-Type: multipart/related; boundary="------------080402040101030305030508" --------------080402040101030305030508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/22/10 11:58 PM, Dean Willis wrote:

<martini-example-3.png>

I suspect most people can tell that's wrong by simple inspection. What I'm willing to bet people are expecting is something more like this:

<martini-example-4.png>

But that's most certainly not the "domain routing" model Dean is talking about. In fact, it's pretty much the "contact routing" model straight up, with an AOR to Contact mapping of "sip:+15005550100@centricvoice.com => sip:+15005550100@pan-am.com" (and a similar one for +15005550200).

No, it's neither: it's table-driven retargeting. You're transforming a request for one domain into a request for another domain, based strictly on the "user part" of the original request. This is ignoring the domain-part of the registered AOR.

No, that's not what I'm trying to show here. The user portion certainly could stay the same, but that would be local policy, not built-in mechanism. My example would be the same thing if the user portion were remapped via some transformation. For example, the diagram I included originally would be the result of a transformation like this:

/sip:(+150055501..)@centricvoice.com/sip:\1@pan-am.com/

But the Pan Am PBX could just as easily have requested a transformation like this:

/sip:+1500555(01..)@centricvoice.com/sip:extension-\1@pan-am.com/

And it would all work just fine:



So it's not contact routing; remember, contact-routing takes as its input an AOR. It looks this AOR up in a table populated by storing AORs (including user and domain parts) received in REGISTER requests, returns the Contact matching the AOR, and replaces the request URI with the Contact before proxying the request on.

I don't know where you got the impression that I was proposing to ignore the domain portion. If the "CentricVoice (SSP)" entity wanted to treat incoming requests with different domain names as different, it certainly should be able to.

By matching only on the     user-part of the AOR, you;re doings something that isn't quite contact routing.

I never proposed that you should be doing this.

----------------------------------------------------------------------
*WARNING* *WARNING* *WARNING*!!! If you are not Dean, the following example and my response may be very confusing. Dean is discussing some valid but highly esoteric and unlikely scenarios. In particular, he is using user names that look exactly like E.164 numbers, but which actually are *NOT* taken from the E.164 numbering space.

What happens when "+15005550100" is a valid user-part on both the pan-am.com and braniff.com domains?

Then you're going to have to use a different AOR on the CentricVoice service. Both pan-am.com and braniff.com could define their own remapping rules that, when applied, transform incoming requests at centricvoice.com into "sip:+15005550100@pan-am.com" and "sip:+15005550100@braniff.com" respectively. The Pan Am PBX could, for example, register for:

/sip:pan-am-(....)@centricvoice.com/sip:+1500555\1@pan-am.com/

While the Braniff PBX might register for:

/sip:braniff-(....)@centricvoice.com/sip:+1500555\1@braniff.com/

----------------------------------------------------------------------

Okay, great. So the "contact routing" approach works fine for the later cases. But what about the people who want to register entire domains? That's the neat thing about the "contact routing" approach -- if done correctly, it works just fine for those cases, too. Going back to the first example; if we perform normal "contact routing" -- URI rewriting and all -- and have the PBXes register their IP addresses as the mapped contacts, everything works fine:

<martini-example-5.png>

This is great! Now we're using REGISTER to put an AOR to Contact mapping in place (like it always has) instead of using it to install rules to override normal RFC3263 handling. Best of all, we're not saying "ignore DNS and use this alternate mechanism for turning names into addresses" like we have to with the "domain routing" approach.


Nope. What happens when the PBX supports two domains, and there might be user-name overlaps between the domains? If both dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are contact-routed by the SSP into dwillis@10.1.2.3, we have something of a mess.  This requires sending the untransformed r-URI to the PBX.

No, it requires having a mapping that allows the PBX to properly correlate the r-URI with the user. You propose that this must be a unity mapping. But we have a clear existence proof that this works with arbitrary mapping, because THAT'S HOW REGISTER WORKS TODAY. The UA installs an arbitrary mapping from AOR to Contact address. And many, if not most, modern UAs can handle multiple registrations and figure out (based on the r-URI) which user an incoming INVITE belongs to.

You can get rid of most of the problems we've identified by allowing a programmatic mapping from AOR to Contact value. Your example, for instance, can be solved by having different mappings for each of those users.  I already showed this in an earlier message, but I'd like to reiterate it here, with some alternatives. You can trivially address the "@mktg..." versus "@eng..." issue with mappings like this:

1 full
/sip:(.*)@eng\.pan-am\.com/sip:\1-eng@10.1.2.3/
/sip:(.*)@mktg\.pan-am\.com/sip:\1-mktg@10.1.2.3/

Alternately (since you raised UUCP and email), you could use a syntax like this:

1 full
/sip:(.*)@(eng\.pan-am\.com)/sip:\1%40\2@10.1.2.3/
/sip:(.*)@(mktg\.pan-am\.com)/sip:\1%40\2@10.1.2.3/


Also, what happens to security assumptions around the AOR-contact mapping as assumed in draft-ietf-sip-outbound? We end up with traffic for multiple users occurring over one flow, and that leads to the attack-model we panned the early connection-reuse drafts for allowing.

Ah, now you're getting into the arguments that REGISTER is the wrong tool (or that REGISTER needs to have a Proxy-Require) for this application. And we're in complete agreement there. Any use of REGISTER for multiple AORs that correspond to multiple humans[*] is going to be broken from a security perspective. I raised this issue at the microphone in Hiroshima, and I jumped up and down on it a lot on the mailing list in early January (e.g., "You are changing a fundamental property of a core SIP construct -- the operation no longer applies to just the user indicated in the 'To' header field; it applies to myriad disparate users. Intermediaries assuming it means what RFC 3261 says it means will be mislead, and make potentially incorrect policy decisions as a consequence"). Believe me, this issue is near and dear to me. If you see me proposing something that you think means I don't care about this, then you're reading it wrong.

/a

[*] I'm avoiding the use of the word "user," since that word has been hijacked to mean something bizarre in this conversation. --------------080402040101030305030508 Content-Type: image/png; x-mac-type="504E4766"; x-mac-creator="0"; name="martini-example-10.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename="martini-example-10.png" iVBORw0KGgoAAAANSUhEUgAAAlQAAAEwCAYAAABxFe/4AAACLmlDQ1BJQ0MgUHJvZmlsZQAA eAGtk81rE0EYxp9tkHpoQy2lFE97KMVD1G3air21zYfEhrgkKVUvmuxuPjTZrLubqNWDf4UU RBC8ePDmRS/aowhaRRDpXyB406IHKeszs90EweDFd5mZ3z48887MO7tAbL/iOK0RAG3bd4vn 1tSLly6ro3tQMIVxzGK6YnjOqq7naRkSPz7Rzfh4UuQaYhomx10uCCgJGqbqIa8IroZcFnzT d3x6GoKNRsUk3yUn3HIxRX5CjtdDfi64GvJrwT2jLuZ+Jmu22bSBkaPks6blGeQVct30jDaZ eRS02x3mj4mcJwzH5dzYe/KsqAtHxo04sPyV+sOBduU08OwNMK0PtLltYPIq8GJ5oH3flbVS ZqpebSEp0yljx4EjO0HwLQBG6T94FwS/toPg4D7X2AdeFYyu25NeblB5C/zrPTxzmB34wDMw 5B39ncO6SJcGPN4ByveAPMcHHOd+AsfuADqos0wLC1ELa0gZGE9n8nk1uagtZfVNqfzHrt3q 8q5kTLIfs6uFCxxn2L44vs5Nhez1SpmIa81sLmKzkl6PeKuRKkRcc7PFiK9VzosDypyWvVGK 2GnJb/9wrbW+3/Iyfc9WoyzOLD1ut7gR8fXOet9vWun+3uxWQfxP0t/0c/39I40M8nxUJLEI DUvIsuyb4TfJGZh4CjyamE+dKb3c3RPCH+Fbt+RdpzrObbdZb/jqKv9IK6HmbONUQk1q8xp+ A4mVqh+gMeH6AAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4AexdB5wURfr9ejawCywZ yRIMCEbMWVDMOZ85/s2eOaOu2fP0MOuZMCfMOaBgwjMQFUSSKBIElrSBDbNd//e6p3Z6x9mc Zma/b39vK3RVddWrnu43VTXVImrKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwo A8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKg DCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDyoAyoAwoA8qA MqAMKAPKgDKgDCgDyoAyoAwoA8qAMqAMKAPKgDKgDCgDScaAk2T11eoqAwnDQFZv10Vl9DOU MD3SKBUxxYtDoUYpSQtRBpSBVsVAeqtqrTZWGWhcBpx1i1RPNS6lLVtadh+jHdqyXaBnVwaS lgH9Jpa0XacVVwaUAWVAGVAGlIFEYUAFVaL0hNZDGVAGlAFlQBlQBpKWARVUSdt1WnFlQBlQ BpQBZUAZSBQGVFAlSk9oPZQBZUAZUAaUAWUgaRlQQZW0XacVVwaUAWVAGVAGlIFEYUAFVaL0 hNZDGVAGlAFlQBlQBpKWARVUSdt1WnFlQBlQBpQBZUAZSBQGVFAlSk9oPZQBZUAZUAaUAWUg aRlQQZW0XacVVwaUAWVAGVAGlIFEYUAFVaL0hNZDGVAGlAFlQBlQBpKWARVUSdt1WnFlQBlQ BpQBZUAZSBQGVFAlSk9oPZQBZUAZUAaUAWUgaRlQQZW0XacVVwaUAWVAGVAGlIFEYUAFVaL0 hNZDGVAGlAFlQBlQBpKWARVUSdt1WnFloP4MLPnLyLp1pv4FtEDO0tLkqm8LUKSnVAaUgRZk QAVVC5Kvp1YGasvA6Rcaye4TxYbbGrl0lJFw2BcZRRBH7foZOeW8yqLj/U+M7LhvNO7RMUZ2 3s/IfkeLbLqLyOEnG/lrefR4sD4bbRc9H8/dYxMj+x9r5M/F8dMH8za2P2+lkX5biBjT/Odu 7LZoecqAMpCaDKigSs1+1ValGAOTpom8/ITIukWOrPnN93/4mchdD/gNnfazSLu2Im99KLJy VVR0TJ4usjWECG3cF0beeE/k3RdFpn3pyIxvRBYtEXn6Jf948P+yFRROIotn+Ofkead/hXw4 zxPPBVM2j//HqSJbbS7iOE7znFDPogwoA8pAHRlQQVVHwjS5MtDcDOQXGJk9LyqMMjMd2XYr R07EKNNnX/i1oXDafy+RzYeIvPRGtIYUYtts6YdvuktkX6Tp2sUXJdnZjtx5vcjew6PprW8y 8m0wUKRzp6iA6dHdkX59RPr29lOtwKjRGf80wtGyfY82Mnd+VMi9/KaRLXf3j426LRr/+rtG ttnTyHqDjZyM0bTCIv/Y7aMNhJqRE88x8ghG0UpKjFx+g5HNdjVy7BlGPp0QbYeto7rKgDKg DCQSAyqoEqk3tC7KQBwGpvwk0q2LQMxExQ2TZWeJZLbxM1AADcNI1OkniIzBCJS1KRyhigiq Pr1E/o0RLQoVjlYVFxvZc3cHI1iVy2VeCjGObHHdErF4qcFomJHVa0T+cYRf+qE414D1RT4e 6wu5cy7z4199y8gtd6MeD2L06yGRh58S+XGqka+/M3L7aJFnH0b4c5FfZos8/qyf58NxIvc9 JrLlZpiGPFDk/CtF5i0Q+e9/RHqsJ/LQk1FB6efQ/8qAMqAMKAPKgDKQEgxk9XaxpKfpbfQj rjn4+L+f66JrXXPJdX78lru75otvXLM23zVdN3TNd5Ncs3CRazoMcE1pqZ9mzVrXPPC4a3ba 1zXZfVzTdzPXvPDa38tli444xTVsXxDMM/UnP/17H7vmmNOjeSdPd836W7gmHHZNv81Rl4nR Yw8/5Zr5C1xz4D9cM+6LaPw1t7jmnMtcU1bmmo4DXfPRZ/6x3//0yygo9MO/zvHrwTKa2tje lLg4tRHKgDLQ7AzoCFWzU64nVAbqxkBwHZTNWV5u5KPPRE46VqSg0Mic+f7oTk57R44+1B+l Yj5OAWZk+CNQHXIcueBMRyZ+5Mis70R23ZGjVbbEyi5HvN7D2qoVc3z88i1GirqLvPCan+7O +0S+mCgyaGvj4ZDj/ZGkb77HqFmmyG4o29q5pzmyCiNbv/0hsuduNlZkbb4IR81m4Rzdu2I6 ck+/ng9hrdgJmM5s19YPt8EoXKeOIgP7/30kLVqa+pQBZUAZaFkGVFC1LP96dmWgRgY4/cbp vKA9+4pIhxzEb+4IpwQ59daxgy84OO039m0IHiw6t9N9/KXfpxOigy/rY/rwpGP8acNgufRz em/pMpHtt/ZFDYXNgPUd2WUHkfR0PzXP+QHqMOt/Pn7GucbjnHPmifTqEV08zl8QfjnRyFSk 79EtGl9W5gvCU48T8aYlA+2bioXvFG/W3nxfp/ssF+oqA8pA4jKggipx+0ZrpgxgzZKR+Qui goqjUQ8/ZeQ2rC166n6fII4m2V/yMWa7YQ5Gc/BrvOexkDsiVCi1PvvST8//XOj+2LMYCToq Gmd9LG/DQSIc7Qra0r9ENkI8pt0g3jDi9DtHoxxZulxkh33EWzjP+GUIr1pthKNo514usiZf pC1+gbgY+RlPe+oFkREYrerb2xeE/AWftfbtRGZifZWL2bdFS7hIXRekW27UVQaUgcRlIPJ9 M3ErqDVTBlozAxy9oQ3env+NN/qzx84i70CQDB3sCx4KoGEBQcKUHKW6dFR0hOqWawW/qsO2 Ch/gF3YYKSouERm5h8gNVzB1ZeNUYWx5TLFgoeBXef4o03WX8ld6Inc/aCRvpcjt1/ujZRsN MjL6EUw17upPAR64t8jB+zqY3jPyn4f9va+YhtN4Yx7wz8vRqyv/Ga3DP/9P5NCTRCZ+L0Jx 1RfTgnakLZpKfcqAMqAMJBYDlb+CJlbdtDbKQEIzwAXM3J8pWYw7o3P7hS6d//6Lwfq0YXke pgYx6jR4Q3+kKljGH4uMJ4RCoSg/HLHi+bkeqlePaHwwn/VzZG75Cn+krDn3nuIGpsWLA5W2 FVJXGVAGlIEaGKj+rlZDZj2sDLRmBpJNULXmvqpt21VQ1ZYpTacMKAOxDIRiIzSsDCgDyoAy oAwoA8qAMlA3BlRQ1Y0vTa0MKAPKgDKgDCgDysDfGFBB9TdKNEIZUAaUAWVAGVAGlIG6MaCC qm58aWplICEZmDPPyAef+lsSxFZwxix/883Y+IaG+a6+iT/EP2dDy9b8yoAyoAwkGwMqqJKt x7S+ykAcBp57VfCuvDgHELV+X5Fxb8Q/1pDYFx/D5p/DGlKC5lUGlAFlIHUYUEGVOn2pLUky Bl5+0whHeTbc1sio26IjPd98b2Tk4X78BVcZCYf9YzfdZbAhppFjTvdHnM7CXlDcZPP20UYe f07ktbdFvvqfH37iOSMnnsNNMY3cD+HD3cdps+ca2f9Y7Gc11MjxZxlZ8IeRBx43cv3t0fP/ vtDIPkcZ4TYL834zcsgJ2LtqsMHmnUam/eyn44uOuTFoerrjpbt0lJH1tzCy24FG3vnIT8O6 3fuokWHDfbzwWvQcfm38/zxPvPx8efNVN/lt5Stu2BYayx1xqJEXX/fPx3N+P9kI+dhgGyOn nm+8TUH90vW/MqAMKAPKgDKgDCQ0A9w2ob72ypuuGbqzayZNc81X/3NN50Gu+WGKa2bPdc3G 27nm1bdcw5cCb7Onax560j/Ptnu5Zvu9XfPN96557lX/hcF8AfKfi13TZQP/hcTr1rlm1wNc s9murrnrAdcs+cs1zDfha9csXeaa/lu65tmXXTN3vmv2PsI1fEHxo2NcM/LwaFv4wuJb7/Ff qsxyWJcVea65Mtc1ux3op7vjXtdceLXvP/YM15x5kWt++901t9yN+m/vx//7QdccdJzfrvc/ 8V+AzLrGWlX5+eJnnoP1/mS8a3L6u2bBQp8jcn/eFf5LoHfYx2//My/5L4jmMaarjzFvQl90 WjllQBlQBpQBZSDVGKivoAqHXdNvc18A2Yf+w0+5Zv4C15x+oWtehtiyNuo211x8LTYQhVBq 1881M3/1j7EMnj9vpS9kemzix5eV+cLlo8/8MPO1X981q1a75oKrXPPPa6JlfzHRNe985Jpx X7hmyE5+PEXRhtu6pqDQNWNedM25l0fTU/CtN9gPUwQ99YIv1AZs5RrWh0bhRbGVX+ALRoat 8RwUj0Gj0IuXnyKKwrKkJJqeQu3TCa6hGB023DWu6x87+rRou0pLXdO2r2uWB84bPF9NfhVU qfYp1fYoA8qAMqAMJDwD9RVUFDIbbBMVBPYhT0FFMUCBMXCYj24buebO+/xRnk12jIqLWRi9 oiijvfm+a/Y5yvf/NNMXRLZMiiDmo/hYfwvXTPw+WoZNs+AP13TCCBntrEtd89gzfnoKoMnT o+k//9I1W+3hhyl2eOwiiL3Lb4imsWX+52HXdBgQbQfbQ0E4Z17ltFXlv+5W1xDWWP/em7pm xix/VI1C0xpH+v73ox+e+pM/CmeP1dVVQZXwHzutoDKQsAzou/wStmu0YqnKwBy8fqVXD/+d eGzjX8uN/DpHZPVakUEDRCZ9Fm352gK8qgUvHH76JZFtt4rG83179oXCfBeeffce3/0XfFGy PbYGZS/Dq1z69I6WwbVO++3J19AIXmQs8uNUIz9MFnnoX3ihMdLz5cc914umf+1dkbNOEVm5 ysiSZXgv32D/hcj7DI+mmTTNSGe8WobnvegskVGX+cfCKL+4mK+9qfxyBr6KJl7+ych/wMho ueO/wrsLN/bfXzjlJyNnox60NWuN/PGnyBZD/TDPa3nxY/S/MqAMKAPNw4AuSm8envUsykAF Ax0hkJYtF1m12kDIGDn3cgiDfJEcvAiY768rWue/G++dj0T2PoLCS2QKhIIVTSyIwsEKp+kz RYZs5BfPdEFB4eXbQqRNJoAXElO40Z592cib7/nn4fv2BvUXuRgvUL7xSn+heUaGCDHzVz/9 /AVGPoeoOfUf/rmHQkxlZjrSMQdlzvUXiv+52MjpF4p07oSXGreHIPuDZfli7cKrxFscz9K+ m2Rk7nx/qVKV+duKzEJdMcIkZWVG7sGLlS87368L2z4MbaJNw2J7vkswO9sXahRiQZ78VPpf GVAGlAFlQBlQBhKWgfpO+XF90c77uaYPprC2HuGa62/3p6u4Dmnfo/11Spvv5i8Un/ebf4zp x38VnebignJO9dE4TcfpvD/+dM2IQ1zz4bhoOubjuiPaTXf5U4rbjXTNAcf6C829A/h35Kmu 2ePgaD7GX3uLa7L7uGbPQ12z6S6useuy7n7INWfjnDROIXJakse5OPzjz/34n39xTd/N/MXx rBsXmHN9F23wDq556Y3q83NalAvtuVaKU3qsC43Tk5z6s3bvo1gQf3E0vPtBrnn7w2jYpqut q1N+Cftx04opAwnPQOXx94SvrlZQGUgcBvjwXbeo/h+hPxYZ6dtLhCNE1vDgx+iNSFoap/+i 8fZ4Ve7qNUY6daw5fd5K4408dcipOS3PtWiJkYJCkQ0Hsk7x85SUGMlbJdK7Z+Xj3PZgDtrS u6dI1y6VjwXbUVX+gkLjTTsOxOhZ+3ZV5w+W1VC/vhy5oQxqfmWg9TLQPHep1suvtjyFGWio oEphapK2aSqokrbrtOLKQIszoGuoWrwLtALKgDKgDCgDyoAykOwMqKBK9h7U+isDyoAyoAwo A8pAizOggqrFu0AroAwoA8qAMqAMKAPJzoAKqmTvQa2/MqAMKAPKgDKgDLQ4AyqoWrwLtALK gDKgDCgDyoAykOwMqKBK9h7U+isDyoAyoAwoA8pAizOggqrFu0AroAwoA8qAMqAMKAPJzgBe DKGmDCgDykDyMMANPxctEVkM8JU93Hi0ECgoAgrErFnrlOIdiGG2KLuNhLKyJC07y6Tj1Tsh vn6Hr+FZr7tI/74i6wPB9yomDwta0wRnIN4ej/HiErwZKVU9/31XlZsUL65yijqEVFDVgSxN qgwoA03PwPI8f4f1uXhx8twFUo6XNK/DC5DDi5dKaHmetMGLnJ3sbMlrkyGLsLH8GteVteFy s6akVFbhBcyrHMcUAGvFOGnGkTbiShu66aFQm/RMt11GmmRltQkNdF0zqLhUepWWSNv1upl1 /fo6eIWz4E2EaspAnRmgWLKCKdZvC7PHbVjd5mUgKJ6sn248f71qpoKqXrRpJmVAGWgIA3wp 9NzfRH7+hS9XdtyffzFFv8x2wgsWmmwIoHB2W/nDiDNz9Rp3ipSbxSZkFhnXXVRaXLRIVnde XVCPk5dWmWdh9iJ3vf6L/wr1d8Xg9dRqykCtGQiKJy6hYdi61s/CgukYVmt+BoLiycXpbdj6 6bKfbHyda8jMasqAMlAPBvTVM7UjbdkKI9Nn+OJp8nQpnDJNwr8tlHZtsyQvI1Om5+c7k4pL y2cZ18wOr1s3W/I75NWuZE2lDLQoA1Yk0aWIssCbOD0/XXvMpkWUF0dXrXkYoECiWaFkBRRH pOm3Lv32mE2LqNqbjlDVnitNqQwoAzUwsADjSlN/Fpk83Ql/+4MpnD5TMspKpTw7S+bgJcjf F64zk8pdd3pZaMXPhXN6Y9WTmjKQtAxYkUQhRfFksRp+HlNLfAYonDjNT1FF0CiqaFaI+aFa /FdBVQuSNIkyoAxUZgDrj2T2PPHE06SpTum3P0rRjFkmOxSSQiz8/il/rftlabmZVFpcOllW tl24qnJ2DSkDyc6AFUxWTPFZSmQAjsHiPrXEZ8CBoZb4qYqUAbZPWXGKK4br1JEqqEidmjKg DFTJQGmpkZm/+uLpx6lS/L8fpQRiqm1WG8lLT5epq9a4XxrjTiqRdZNlcQddg1Qlk3oghRjg wzY4xcdnKX4/6j2cU6iZraIpWWilFVMUUBZ2+q/WJKigqjVVmlAZ+DsD+QVGctrbz+Lfjydb TN5Kf73TNKx5+mGqUzBpqnH/XCxt27eTRWjlj6vWmK/LxZ0cLls9Jf/37ti0QE0ZaLUMWFHF qT6OTHGkgw9nteRiwPYZhZRdR2Wn/erUEhVUdaJLEysDUQZ6dDdP9dnMOWHLTU3x4Qc6OfuP NKEhGyeHuOJeTr/MFpkFzJztlE2eboomT5PM4hIJdciRWSXFzreFBeU/lKe5U8sW/z6jUDYq ibZcfcpAq2cgVkxRUHGEKrvVM5N8BLDPKKA4zRcUVHUWVclx90++DtIatxYGei9u26Z8vT1z OqYdZlw5JCvLtD14XycEcZU9eEORDQZgYUV6y3zMysqMYP8mWbBQ5HcAWxSUTv3ZKfp1rsnA hpiZOe2c3x0xP69aa340YfOTEwrd75qyA0uXtsH4lJoyoAxUw4AdlaKI4ghH2wjaw/1O11CB hSQwfwmV7ICqcicW/kiGKAa4ywrXVdmF6vDWbC1zp6+5XppCGUhKBjJ7lQxJc9IP7NTZOTBc JpsUFUm3Pr2laPMhjmy1ubQfOtiENt5AME2In5Z0FMFokEQ+1LVuLxeE52GVd95KkRUENhmg f+kycTHqVDRnvoT/XOykr15tstu1lZXYmuAP7Pv06+rVMgXLA35xTNnM4r+yFuDM0QWX3Qt6 ZmW0nVm82OlaKb7WtdKEykCrYYDPTSuoOM3HEQ4KKnyaPWBNYfSjhTi1BGUgcu/dHdXj8gWC gmodwBF5K6hq3ZkqqMCamjLQdAzMaZPRvf8QJyM0tE26sznWW22Pnb0HhsslBzt7ty8rkzZt s6UEa5TKOnYQFwLLLS0TJ4wXp5SXO1IWNg5dCCIHOkrWrpXMonWSiV/SFWVmyBosCl+JD/Ey 7BS+tLAwND9cVv4bRBMQXlC89F2MSx1Tq29YmT3Dx2CE6oSSxaFDm44LLVkZSAkG+NzkchlO 89nRqXbwU1DxJ/ifqqACC0lgEUG1N6rKrS4oqAoBO0pFQcVXWNVaUOkaKrClpgw0HQMblZQt l6kofyrHkPmJrWy5oeIOl3QqzG/TecnyUGe8K6V9GPoJf2EnZML4HVHYKY+4YRMuyShdJYv/ s3Kd5NZ5fr/yeSuHHHF2E9d8VTlWQ8qAMlANAxRWwV/6UWARasnFgO03jjra/qzXYJMKquTq eK1tyjEAYbQ2d2XJWsGknT/G3BJNdIz7ZnFxIaYE1ZQBZaCODPAhzIcxoc/UOpKXAMnZZ7b/ 2Jf1Nu38elOnGZWB1GGg+K+Mz1OnNdoSZaBZGOAohoUd2eCDWS25GGCf2f6z/VmvEaoGqbHk 4kxrqwwoA8qAMqAMNCoDwQewfSg36gm0sCZnwPZbsC/rdVIVVPWiTTMpA6nDQJse4YPa9Crb N3VapC1RBpqUgeCDN9avz9Qmpb5JCmefxfZjMFzrk2rn15oqTagMpCYDTlroWmygwDXzasqA MqAMKAP1ZEDXUNWTOM2mDKQGA79l4TfBW5UsXfq/1GiPtkIZUAaUgZZhQAVVy/CuZ1UGEoKB rJ59d0RFpon042Z2asqAMqAMKAP1ZECn/OpJnGZTBlKBAVdCuxnR/adSoS+1DcqAMtCyDOgI Vcvyr2dXBlqUgdKigodk7TLuDqymDCgDyoAy0AAGVFA1gDzNqgwkPQNrO3obiiZ9O7QByoAy oAy0MAM65dfCHaCnVwaUAWVAGVAGlIHkZ0AFVfL3obZAGagXA5m9w8e16Vl+Wb0yayZlQBlQ BpSBSgyooKpEhwaUgdbDgGNCxxpj/mw9LdaWKgPKgDLQdAyooGo6brVkZSChGXAc2b20vOTL hK6kVk4ZUAaUgSRhQAVVknSUVlMZaEwGMnuWDDVGVsmKdksas1wtSxlQBpSB1sqACqrW2vPa 7tbNgJM2TBzzZusmQVuvDKQmAyeeeKJkZmZK+/btpV27dtKnTx+5+OKLZc2aNY3a4Pvvv18c DHV/9dVXjVpushamgipZe07rrQw0gIHSJekvlCxOu7wBRWhWZUAZSGAGLr/8cikoKJDCwkKZ MWOGfPDBBzJmzJhGrfHzzz8v22+/vbz00kuNWm6yFqaCKll7TuutDCgDyoAyoAzUgoFOnTrJ cccdJ+PHj/dSL1682Atz5GqfffaRzz77zIufPn26nHbaafKvf/1LBg0aJNtss41Mm4Y3U8Wx X3/9VRYtWiSjR4+WsWPHSjgcrki1//77y7PPPis77LCDJ7gmTJgg5513nvTt21eOOOIIKSoq qkibSh4VVKnUm9oWZUAZUAaUAWUghgGKoldeeUUodGgPPvig9OrVSyZPniwnn3yyXHDBBYJf /HqjWRx1ouD66KOPpH///jJq1KiY0vzgCy+8IMccc4zstNNOkp2dLePGjatI99NPP8ljjz0m 9957rwwbNkxGjhzppXnvvfeEQox1UVMGlAFlIOkZyOgVPimrt/tq0jdEG6AMtAwDHIjIBHKA HsAGwDBgBHAUAG3SsnbCCScY1sMiFAqZvffe26xevdqr2Ndff23y8/ON67pmypQpXrq1a9ea iRMnmq5duxqMNnnpvvnmG7PRRhvFbczAgQPNd9995x276KKLDIRZRTqMfBkIMi+M9VUG67m8 8zECa7nM1VdfXZG2JT0Rfthn7Dv2IfuSfcq+ZR/XadBJXz0DxtSUgdbEQEgcfSFya+pwbWur ZICL0O3oEhemZ2VlVfDA6bnDDjtMIKZks802q4inp0ePHpKWlubFcVH7unXrKh1nAEJLfvvt NznnnHO8Rel5eXmyatUqKS4urjgPp/doXBy//vrrewvkGU5PT5eysjJ6U85UUKVcl2qDlIGa GHB2c8vCD9eUSo8rA8pA8jLAaTiMNv2tAeXl5XL88cfLHXfcIZ988omUlpZ603E2IUazrLdK l9OCp556qpx55pkVaTAq5i185xopWm3KqcicIh4VVCnSkdoMZaBWDPTM7y6O9Cpbfvv0WqXX RMqAMpBSDHAkiSNKBx10kCd6nnvuuTq1jwLs1Vdf9dZYbbfddhV5Dz/8cO/XflZQVRxoRZ6a pWgrIkObqgykOgMZ0magEXOHSK6b6m3V9ikDysDfGejWrZs3usTF4sTUqVOFwojbLNTGPvzw Q+nYsaOXJ5iegur9998XrM0KRrcqv9OqWquNVQaUAWVAGVAGGsYAByI4u9MGaAu0BzoAnQDO sY3FQms4iW1LlizxNv3s0KGDcBoQC9bjThEmdisaVjtuSgo7GsgDVgNrgQKA+zqUANwLotZf PnXKD2ypKQPKgDKgDCgDrYkBbptgjYvQ4623ssfVrR0DOuVXO540lTKQAgzkhjJ6lm6PX1Pr yHTz9ibXqx0fOeUEuL8DHNmwxpEODml0A24DvgBi7UVEPB+JtOVdiXBpBOVwCRu+Ef5DAO8n 8THu33+2hQRqyoAy0DAGVFA1jD/NrQwkDQNtel23d5qTfpfgJX5JU+nUrCinh66roml8h8eu wHqB49wP50CAoipo6EtvrxwefwgYEwjfBD9tBkABHUQ2D6gpA8pA4zKggqpx+dTSlIGEZcCR 0G4YsPgqYSvYeipGIXQusFGcJv+MuJnAYYFje8HPjXs+DcSpVxlQBhKMARVUCdYhWh1loOkY cHY3jvtl05WvJdeSgYVIdzfwQBXpORJ1ZODYEfC/BtRnN8SOyPePGGyDsForZ+DEE0/0Nt3k 5p3c+JPv9eNmoGvWrPGY2XHHHb3NOLm2igvXe/fu7f0SkAvYudnn4MGDBTukV2Jx33339d4R WCmyFQVUULWiztamtmYGZmRi5dS2JeV5E1szCwnU9ntQlw2Bw+PU6WXEjQA6A2nAoQCnAutj LOOsGOxSn4I0T+oxwK0SCgoKvHf4zZgxw9uYc8wYzhz79uijj3p7VuG1NMLtEh544AHvnX3c NJQvP37kkUeELz6m8d19fIffQw9x9rl1mgqq1tnv2urWxkC3Ad2MuGfIXz0LW1vTE7S9/Ek2 v96PBoIL1Fnd34BJwMEA11MxbX1HFh44pPEAACAASURBVBcg754xuB9hNWWgEgOdOnXyRpfG jx9fKd4GhgwZItzDKrLVgOywww5yxRVXyGmnnSY///yzN3r1xBNPSJcuXWyWVufqtgmtrsu1 wa2SgRXtFuPnX/Ud5WiVlDVDo9/HObiW6to452JfcdqP4uoVwABqykCTMTBt2jR55ZVXvGk/ exK82Fj43r+SkhJvZIrv5xsxgoOnvt14443eZp4UV3ydzQEHHGAPtUpXR6haZbdro5UBZSBB GLgY9TgnTl1eRRwXox8NNEQIc8qQQwax4K/+1Fo5A3yfH0eciK233tp7ifFxxx1Xwcr06dPl 448/ls8//9x7GTI3/5w3b17Fcb74eOTIkVJUVCQHHsgforZuU0HVuvtfW99KGGjTs/w8DHZE XzffStqdBM2cizrGm4Jbivj/Ady1mdN/9bVNkDEvDnLqW6DmSx0GuAh9xYoVHgoLC72XJfO1 MtbOP/987/18HLn68ccfvRGoBx980B721kw9/PDD8n//939yySWXeMKq4mAr9KigaoWdrk1u XQxk9C4dhq+gF4gMLG5dLU+Y1m6BmvCXe7ThgN2gk2HadQBHjFYwELCR8A8OhK03WJ6N+yc8 Z9pAxH0HLsuNh7UxaTXYChng4nL+io/Iyqr5+9bQoUOFU4M0/trvjDPOkPPOO89bnE4hdsMN N7RCFqNNVkEV5UJ9ykBKMhAyabtjCc6XKdk4bZQyoAw0GQNcO8XpPI5evfnmmzJ69OiKdVL3 3nuvLFu2TG666Sbhq2s4UnX//ffL5MmTm6w+iV6wCqrE6CF+C+Wi0wyge8T/CNygnYjA55GI 2XAx4lDJ+PUiHzgECJb3HcL2dRQ8B/eyseHN4Oe3ZcbH4lnEqaUEA85uRjf0TIme1EYoA83J wJlnnuntUcW9qrjn1N577y2XXnqpt46Ko1Gc/uMeVrSdd95ZTjrpJG/6j6NXrdF0YWJi9DoF 0CwgE+Aby5cBXPewL2DXT1BQnQ7sCdwEYNdrzw/Hs4Px/xmgJzAQsOUFNwNcgvhTgE8AaxRU cwCWqZaCDGT1cpcVlxRvIyvbckNJNWVAGWgYAxyISAfaAG2B9kAHgPfursBYY/j9VC3RGYhs AcEffvB5uxrgVDjXLRYB3K4kDLhArYwXhlpiMnAzqvUQ4MSp3kuIwzSON5plDx8BzxsAR5/q avrprytjSZP+t6xyJ7yfiqmk6bCmrCi/sA0B1gf03t+UTGvZrZIB/VAlbrc/jqpxCvC0OFXk 6NNPAHdQpvHbEkeoKLTqY5sj0z9iwKlHtaRnYGBx2eLMllzUwI0rb2liGvml40KAn5fGtqao Pz+33FuKn9d94lT4eMRdFBO/McL3AR8AVwDBe3dN5W2B9G8BTwMnAPyy9gvAUWmOsqgpA8pA IzDAB7FaYjLASWiuk+KN8M04VeTNmKNSTwAcreLI1HigPrYNMnGoOmi84S4PRqhfGagHAxRT TT0CSnFxPzAGCE5xI9hga+z674EaPQpcB3BDH065HwtMBIYChwOXAC8D1jil9A4wDmA+CiF+ 4bkSqK48HPb2ssKWGfJ/QCGwJTAF6Aww773AuYCaMqAMNJCB4LecBhal2ZuAgW9R5kfArXHK 5g13T6AjQGH1KlDruV6kDdrTCLCsIKYFE6g/ORnA/lMPSNeiPs1Q+244x3+BJcAkYAeAxrV/ R3o+kQmR8FS4swEbD6+3Wzgf+jSucuUXBa75Gg9sD9A4MvM0PRF7Du4pgP3C8RX8XNNSVX6O 1IwBrgLmA6wnBQatNvXvhXTvAWsAtmE4QKuuXD9F9D/Fzd3AU8AXwNvAaQBtAMB6LACCti8C qwF+waIYugc4AwgB1ZXHL8x3RNLy3vAlwC9PNwKfAxwl4xSg/b38BPjZX/H6Z3/E8/gfAEUg 60m7FGAdxgKLAJZpy4O3kvVG6CWA6T4B9gJo5I/x1wBzgdcA9gv5+R24DIhnvK4/BlYCbwC2 L6vrp/qcB0WrKQM1M8APpFpiM8Cb/3HA1jHV5I3tB+AQ4DCANwo1ZSDKAISUE3KOk7y2fIA1 tZ2DE3AhJx+OFAuPAbSBQH/PJ7IT3FOBowCOtFA0ZQK0UqDM8/nCrCv8+wD/BfilogtAMXQQ cDjAKepdAD7ILwJopwDrAOaJl59Ci4KBD/b9AD6s7ZeV2tSfYuEnYEAk3+twewLVlYvDlWwD hChYrHGUaqNIgNN5lwDjI2HrbAhPbB7yQVFTXXkb4/ivwGqAfL0DPAj8CXwHGIBihGXRquof B8f+DVAIbgvQLOf94L8deBk4DqD4PRqIZxSES4CtgWcB1oVlkz/m6QEcD2wCfAncB1Cs8dw5 QKyxP2YBFFJzgCcBWnX9VJ/z+KXqf2WgBgbSaziuh1uegaWoAm/6dwJfx1SHIupGoATgDbK+ 1hYZ7U3VlsGHW74NqJt8DGS2ydwdPzbig6k5rA9OQnFBewiIFQXeAfzj9cpRCOJkYHdgHMCH Na0zwIf/hsAC4BfgLOAA4HngcmA0kAGcBlDE8csFbT7QCagqP8XLGuBSoBzgOZ8GaDXVn6Jn F+AgYC3wGnAhcCAwE6iq3CE4lgXQfgYGAExrbSE87W2gCncA4nlOa4vgoRiiEBkAVFWe5RBJ PMFyGT0wip4PAYoZCpXFgLV4/TMRB88FvgIyAfbdjoC1V+GhuKS9BVAQsc1sO60QmA28D0yL hMkF09m2817DfnGBz4H+AEedaKwf+Z/MQMQ2hksBOBIoBnKBAqCmfqrxPLntcL6QfAZyyLGL fwZMsV5uRRz2IfEOgkO4ISRy8lyZ/t8ir41IqtYaGQi1xkYnYZsfQJ15E+MNMGhjEegPNHR0 6iqUkRcDlq2WxAzgDV274VnAh2Bz2K04CR/wHIGYAAwE4tmcQOQC+ClSgjYIAd6XvgeWRbAD 3B4A7WmAn4MFwCdArNWU/y9koJii8QGc7fn8Ly3V1Z/tmQUEhQ0F3HqR/FWVS7HxYwTd4VIA dgOs8Zz8bFdnzNM1kIB1LgMoxqor708c7wPQVgE8b19gV4Di8hrgCyBo8fpnHRJsC7D9vwMH A0Gj4LFG8cT6sR9su5+MHEyHS8G1ArgvEmcdXjcULTR+QZzh+fx/YTgZgTC9A4DfAIopGut4 C1BTP9V4ntxCWYpyVuMq2xTY3HFkC0dkK2BrxG8DbIe47UNAuiPbZTiyTYmRRc8UyQs4ptaK GeAFrtbyDPyKKuDz6tnygD8S5d08h9pAwGXa2BsNDwfLCySXXsFAxH8iXEIt1Rgwzm6uhJ9q pmZRpOwH8KF9LPAsQLEfax0QQaFE2xx4yfNF/3G0hQ9QPhj5cKZ1BviQpbFsDAp4eSnGvgGC Vl1+Tg3Zh3YwD/011Z8PeH5+KPZsGYPhfwag2Tg/FP3PNgbtDwSCvAxAeGYwQRz/74jbKhA/ AH6O+JCn6sr7Gcd5fnJOwXsbMBc4A3gI+B9wGRC0eP2zGxJcBZDvecDJwHGAtXhtZ5vSbIKI /0W41wD7AJkARZA18l8Xo7hbD+A5mJf3QV4b44Hq+qm252G/7gzUaKvLsYF4oTyHhBwdVWvF DPDmoKYMKAMpyEDJktDmZUsyOUrQHMYH0AEAxdIYgA/7LCDWjolEUIxsB3wbCfNhPQz4DVgE HA/Q+gEUM0xPYXUfcAFwM/A4wAezAfhQbwtUlx+Hq7Sa6s86LQCOjJTAem0ETIyEa+twhOZU gPde5j8RqKmMd5GGD/eNAbbxasDmqa68UqS7C3gamA9Q8JK7CcAOAKfQ+gBBi9c/myDBNGAe wC/hFC4OUBdj33UF3gPYVycB9THWj0KKQpJ9fRRAOwXgyFnj9FM+fuRjsK4PU3ssPK4ZKckL y7kQUxSnasqA96FWGpQBZUAZaCgD96OAVwEKJI58PAZwaifWdkPET8B3wJ3AdIB2MUBxUQ6c DtwBzIyAD6wpwN3ADwAfyvcCFG0c8eAD+mNgKpAFVJUfh6q02tSfozxPA6zLj8DNAEVLXYzn WQ0sBFjft4FxQHVG4XAlMAmgqOGoE8O0msobG0nzFtwxAPkin+QwB2A9ghavf1jGAIDn/xn4 ChgGHArU1ngtPA2QO2IrgH3JPq2LPYfEQyIZRsF9ApgLXAjwmqE1qJ9uaCd7g5kXUE4GZGNV wnHlClcOub+o4hem3on1X+tmoKqLpXWzoq1XBpSB+jDAUYgBAIVQCRBrjOOISCawBigEqrI2 ODAYWAzwYVwb64REqyMJ65O/pvqz6HbABgBHfAqA+tr6yJgPrKpDARRA3QGeO9ZqU14XZBoE MP/K2AIQrql/2O7fgTDAqUGKSbuGCd5aWS+kYr+vBdIA9lkeUF/jtdQN4HUStDr101kQT31y PEF/GSTUpl5BGIGCn9eRbxytgsDCkNVcLEA/9IECT4xyxLA9QD7YFo7C6atnQEIyWGO/ekYF VTL0esPq2A/Z+YHnt9y63vwadmbN3WIMtOnlvuW64TvK/srkSFCimH1g11YgJUq9W0s9Wl3/ 5HIKtYOciQfh5ehk3is5gcxpw4fyjTzZ3pGfsAB9PW/qj6NVRr6BEjzsnnxPEFJsqaAiZ0lq jS2oOB/eVDYaBfMb3PWNfILjUR6/pd0XKPcK+LcMhDk0zfPTDgWYxwU45P0JQOOH4RJgD2Ae cAfADxKtqvKY50kvRfTfw/BOBHYH8EWnkp2CUDmwMXA+sBEwHrgHYH2s8Vs7h+6PtBFwq6tf TeXx29JtAMv9AygD9gIWAGwb29sUdgAKXQBwhCLWmuJ62AknYZ9yjYeaZaD3Yt7k9yn763eu dUkk41RMUSJVSOtSiYFW0z+5/JKZIxdASF0KBvg84T4IP0M83Wny5RUc5yic5LbHjyYc7Lnl j0y9lJcvpz3g30+b8tnJU6slIQNNeVHcAj5MI3IyFGUdDlAEvRxTLoULbwZ2CH5p5PgecB8F rgMoIp4H+JChAPo3sC3ABZ7bAOMBDvVSfFRVHofLNwNGAdY4BE4bDnC64SPAGkUTR4feAcYB rMdNAD/AVwI5wInAScCGQNCqqh+FVlXlMT/P9zZwLfAtsDWwBGB/9AOeBA4DWNfGtjNR4HtA PEHV2NcD6z4ZGElPa7c2PcKH4GLrVvZX+lNZ5d13wupIcLMRRxwSyXgNqCUuAynfP7kYUXJy 5EKDESmIp25eVxj5DuHbc/PlXYThDZiLX6uG5CJE3pa71hsc4PFQIIV6lYFGZYAX5X8BPrQ5 MsRfj9D+CfABS5sAUDhMBWYDwZEYPvj/DwgaBcbewQj4OfrBUY4fgQcBa/iS4Z3bhoPuKwhc FohgvseBNKAUoMCwtgwenrO68g7CceaPZ88icp84B9jW/wXi94A/D+CHsjfANr0E8PzWqqtf deUx/z0AhSftEeBh4C7gA2A34CLgOMDagfDMAhYC9wPZAG0L4AuA8U8DHQDapcB5wFhgEUCO s4ALgVXAAuBQ4IIIXoBLARq8Hvog/DGwEngD2BI4BaD4tdYJnu+BjkAv4D1gDcBraDhA2wx4 0fP5ffov+Mkj850KWDsLHoo8gvWIZ+Q8Xn72063AYoDtZVt4jdA+BE4GvgN4zuEA+f4TYLva As1ibXqGD8zq7ZqMnqXbZ/Uuz83qVX4HT8xws1RAT6IMJDADuDm1uamDXHRTjiyFa4jcHPkK C9D3qqnaSMf7ftB4T8gEcoAewAbAMGAEcBRg1JKDAfZVpM/Yd+xD9iX7lH3LPmZf19rqlLiK Us9BfBGwBfAU8BhAGwj093xVv9KAhylsyiLprLMdPJvYQMT9AO4lwPiYeD5sw8BrwE8AH8qd ARrJ4QPY2jx4NgLWBwqAhYC1ufBsDFRX3oY4zjK/AvgAPR+wxng+XHk+jlKxDTTmia1DF8R1 A/iQZpv+AwStuvpVVx7L2AN4G+gJ7AScB9wN7Ax8CywD1gNo7B8KoiuAfQDWmYKjA/AZwHIo wthHzwK0fsDtwMvAcQAf2EcDFE7khPx/DlA03QysAHiO4PXA8CyAQmoO8CRAUXIq0A6gUejx uloDMD37dgBwK/A6wPbxoucIHI19sR+wC3AD8DBArijurgHI87HAucAJQKxVlZ/87QvsAOwJ MO8pAG1z4CzgYmAKMA5YB/AGPBjg+ZrHwuG5Bp+jUCj9ebjdw+Xu+Mye5S+lhdK/y+pZxpuF mjLQ6hjAjSkNIuqMbh28+8y9+CrUA4/Q70y57I0Rqd1uLvTuc9XygnT8MqemDNTIQHqNKWpO 0AdJ+HCjPQSM93x//3cjoihaCAqP3QE+gPiwb4gNQub2wFvAKmAUwIc9H4IDAD6QrS2Eh2kH AMF4BL1RBT7MqytvII5nAnxgU/DdApQATwDMR8HyX+AfAAXJUGAAsBawxlEOPPMqhIOND7oD EKiqfjxWXXkZOO4CHMn6GKBR9HwOhAHyPhqgnQiMA95lAHYhMAA4BpgPWKF3LfyLAfJDexWg qKGRd3LxHFAILAPyAdoPwEWeL/pvY3h3AkYCxUAuQHH7awR7w2WZhwMvARsBFEkUKWz3awDr eSAwE7B2Ojx3AXMiOAcu++p8gNel5eI++Nm+F4CgVZX/TCRiHl47NJZ1HPA0QOM1wH5PA04F eJ2zPZ8AbGuzWMmKJb+36dU/hJP1xlqQFWlpaeQpDf43SpZmVPWZbJa66UmUgZZgILe9HIVp vVvF8b7c8K47DTfeUSqQWqI3Wsc5G0NQ3QqqxgBLgK+BfwPBBx2CnvFBZ20BPHxI8mFurQ88 9qHXC/4S4GyAImAroCrjObsA+Kx4thz/OdrRFSgCOBJkrR08cwGOIvB40NoiMA+orjyKAwfg uShQKKKOB54AegO2DizjQIAigHUInisb4TLAPqDh/ZtVV78eSF1deW6kNIrLYQAfshQQvwJ7 ABsCswHaAOAXeiL2I1ziToCjLxRH1liOPS/FlTWKKHIXzybFiRyAuN8Aiika20pRQuNI1MHA R8BeAPt/G2AWEBSRFHvrATMBawPgCbbl2cgBtnc74MpIOAMuy4u1AYiIl5/xvJ6s8dzdbQDu nxF/Kdw/AIopGq9bnquZbCD4dAvxAOkgjnM1LtJMXI3Li8vyTm2mCuhplIGEYIDTeGlp3o+M +LnnXXkOvljckFvg3V/sPToh6qqVSC0G+JBsqJWjgP0ACorXAT7I2gOxxmkka3xYL7WBiJsH 97wIJsAdG/FfCLc62wQHhwQSLIC/COCDmg+4/oC1AfDwIcz4HIBCzNpAeGYA1ZU3HMc7AdYo DFjvjsAIGwmXH9oFAI/9DgwArA2Ah4KGD9yqrLr61VTeNyiUYu4dwAHeBDjStDVwLXAuYI0C guLV2kbw7AasAT4B1gtgffitCLSiDVF1NooZlpsWyUnRcWLE/ypc1n1fYCJA/tgnrGMIsDYY nm9tIOKy3GBb9ka4H8C2XADYtjANzxFrVeXn+fsGEseeuyFcBIptFK8ndNHpmXiAFIkpP1ZW dM9vlJK1EGUgwRnIbSvb5naQTyGmxqGq2+EzsBhj9efgV3tDIaZeRpyKqQTvw2SvXvAhVd+2 PIOMBwDLgDEAhUIWEGvHRCL4QOI3B/tA5EgVR1LwDVu+jGAR3LkR/1dwq7OeOPgZQFHDhzQf nh8DRQCnjk4F2E6KhRMBPqj54PkBOB2gsW4cyeI5qyvvaBy/D6AxPct7HaB4ew44CKCxfRxZ +RB4F9gZ2BhoC1wNsA7VWXX1q6m8m1HwDQBF5hnAocBUYF/gKmBzwNp78OwF9AfSALatBzAe GAFQRNGOByYANd2QKK6zgersDxz8DTgqkugUuAdH/OSfIz43AS9F4ngtLACOjIQpktiXsRyS F9azDUDRxOtyNfA5cCzAa5IYA1wG0HYCtvV8fj/Fy0+OTgKY1wHYx58CiWjzWSk8SNbh/4vF OtWXiH2kdWpkBnJzZBOsk3rNSZcf8AEdiZvUanwGrlmTLxveWCD/za3+y2sj10aLa80MpDdC 4+9HGWOBaUAO8BiwAoi13RDxE8AH4p3AdIB2McCH7BQG6mETkGccwPwUBSHgMIDGulEwLAQ6 AY8ATEs7FeDD9jygC8AHdhiYAFRV3j049jrAtnIq6QuAD/JS4BqA57sNoJi5EiiIgP5JEf9S uMOBmuxUJIhXP4qR6sqjsD0Y+C/A9vwCsJ83ANYCowBrs+GhYJgFLAGmA28C5cADwBxgHtAO OBGoySg02LdsY3XGOrwIkKtCgKLK2ivw3AS8ZSPg3go8B1wL9AZuBsh50CiUPgQoKtjuOwDy z3Owj8gbrw323TkR//lw1wCTgaeBDwCbn+1g3Z4HPgbmAiyP7icAy6JRZNFPl2bj/dDfwza+ 8V1T/ouRtP1RkTXF4VmXxKlL45+zbiWaOMnjxcVJplHKQGUGrsuS/hkZcgOu91Pw6UvDhYRR Wbm/OF/uwod3VeXUGlIGmp4B+xBo6Jk6o4ABwEygBIg1xvUBMgE+wPigamzLQYHrAXxwujGF r49wPhD7IUtD3EYAH5J8CAetpvKKkZjiJWh8mLK8PwCMElQyltcd4AO7tlZT/Woqj6M1mwAU UguAqh5eXXCMIop9E7RuCLDfKMpiBUwwXdDfHgG2neVVZ7wWWP7i6hIFjlHUURSSPwqbWOO1 TPQFKA5tW+01zrz0UyBWZ8zPOgWvIduv5JFlJ6S16VV0vuNk/Sfs5o0IL+0+MQErafuEVbN+ uvH8CVh9rVIiMICpvd74ingdrpozsWaQawXLjCNPlobl5tuLmuXzyfsIv6Ty/spZB97zuKSF X9p5L30dmwbAUUt0BiI7pR+Jeq4EVgO8x/P5UgRQt1AX1Loz7cMGeZrUrKCKN3LVpCfWwlOe AV7D9jqm8KHfutZPEoLpGE45y+j0xYYmvUvH8IrNJyVo44LiiYLVhq3filgbn6DN0Gq1BAPX tpMemSFvdP48CKksaBZeLy+GSyX31pIavyg1ZpV5L7GCikscrKDqCD8F1ZsqqMBCElhEUB2O qlJQcUDBCioOCtRZUPGiaA67FSeh4lNTBhqTASuSrHCikCI4smdde8ym5fnpTzkrW70HR9YI fmtOJLPf8KxQsgKKo5j0W5f9YkUV62/z0a/WShnwRqQgpCCizsInNxtXBa+LsWEjN95aUOmX uc3NkL2e6fK6tddyc9dDz9cwBuz9h/0X7NM6l9pcguqWOtdMMygDNTNgRZIVTxRSBIduU1I0 1UxJ0qXgDYxTJbypETQrqnhMrZUykJslAzChdzkecWdwRMoTUkbeDLty0y2F3lrIRGHGCile v94UEUY+9P6TKL1TfT14j2Gf2fuPvfdUn6uKo80lqKo4vUYrA/VmwN6wrJjitUxkAI4Oudeb 12bNGHnwcC1KGfstcHLe4BhWURUgpTV4c9th38E0jEgZ79fX/ILEa2AshNQtEFI/JRAHrBcf wFZQ8RomjgU4/cd1VVz7yRHjLID3Jt6jeM9Saz4G2D8UTewbrn3mbBnXcXN6j9N8tt94z7H9 Wa/7jgoqMKiWlAzwYcsbU1BQZSLMh7NacjHAh40VU7yRWfDmVq8bW3I1X2ubS6HRXg7DuM55 uBJGRBgpwzqpF3AF/Au7m89MMJaC16gdmeJDm+tu+NDmvYhikMbrmD/qsXEqqMhK8xn5Zx+x Dwiuj6Kgosu+smul7EiVve/U+d6jggpsqiUtA1ZU8cbFb38UU3w4qyUXA7bPeAPjzcwiuVqh ta0zA7nZ+FVuhpyF0agzIaR6sQBcBAX49zjGFP6Tu67iTQR1LrsJM1gxZa9XPqztA5sPZz6o rZiy8RRTvEcx3n55gFetGRhgP7EfOBJFQUURFRRV7DPG234MCirmrbWpoKo1VZowwRiIFVO8 WfGmVdPGognWDK1OpM94E+MNzYop6ypBqceAg2m9vTG2fC4+xAejeWmexDB4K4LBXoEF8lyu Px2T6C0PCio+kCmW+Ey1z1Urpvjw5r2J8XZUHV61ZmLA3ks4AsV+CooqTv/ZUSorqpi+TkIK 6T2zHW/D6ioDycRAUFTxhqUjVMnUe9G6coTKDrfT5UNHv8VH+UkJX2572Qy9eiKm9Y5Hg/qx UZjS40NsLGT0I7kF3psyGJ0MFhRTHPmwSw/sdB6vY4588L5kxRQFlwoqkNDMZgUVBW5QVLF/ 7GgVr8PYtVR1FlUqqJq5Z/V0jcIAH7YW9kbGm5UVVY1yEi2k2RigEOYNjTc4+9Cx/Uu3zjc2 5FFLAAZG5cjgDCNHYePNYyCktghU6TdvWs/Ik1gfFbtBciBZQntjRRWvVRof4FZQceTcTvVZ MWXTMa1a0zNg+4n9QlFlhRNdO91Hl2Ee1xEqkKDWuhiwD1wrqPjlgODDWS25GGCfcVqE/Rcr qJKrJVpbB/tGbYOePAiC6UiIKI5Ked9+8FTj5omvlht5/pZ8712cySyU7UOa9yE+hK1IYjzD BK9le03rdQ0yWsjYJ7a/bN9Q8NIfHJmycXZEi3nqZOxsNWUgWRngTcx+6+MNy34bTNb2tNZ6 236zDx32qX1AtVZOkqbdudwpPEdGosIHodMOQM/18irv9+AqTOu9jbixi9fKp4/5owBJ07Zq KsqHLVvIh681+9BmHB/OvJ5jr2nm8ZmBR61ZGGC/WFixZIUVXTsyZeNsnzJPnUwFVZ3o0sQJ yoAdpeLNS6/pBO2kaqrFPgs+fKpJqodamoGz8MWld45sh0fUnhiB2hP12RkSoWJkGE+hPxD3 vlsuby8tlM9TSETFUm8fuMEHsH1g23sSxRP9QSGlgiqWyaYN236iS7CP6FJA0W9d23c2HQ7V zfThUze+NHViMWBvUvamZW9iiVVLrU1NDOi3+JoYasHjF2IavVOObI2Hxa6oxgish9oNH7j2 dpzFe6eekYmIew+bb76XYJtvNiVzfPBa40PZPqz5YLb3Jt6TaDbsh/R/SzAQFEpWVNk+sy7r FUxXp3qqoKoTXZo4ARmwNyq6dhEpeQAAIABJREFUvHnZG1gCVlWrVAUDtt+CfVlFUo1uagau y5Z+GWmyE86zE0agdsLTZRhc/uDDM3YSRNRMSITPXSOfl+bLhDtFVkUOtzbHPnxJCx/SNCuo 6Ge8taDfxqnbfAywr6xZv+0/xgf9Nl2dXBVUdaJLEycIA7wxVQUVVAnSSXWoBvusqv5kvL35 1aFITVoTA7n88pEjG2JTzWEYddoKomkYhBLF03qV8hoIBCM/oRMmOq58AXd8bqEsrZRGA7EP Y163sRYvLjaNhpuOgXj3kXhx9a6BCqp6U6cZlQFlQBlICgac67Jk/bRMGRoyMgQ1Hoon+1CI qM3helN39kkPMUX1uhIi6zt4voXA+raoUL67SyQ/KVqaOJWM96COF5c4NdaaNJgBFVQNplAL UAaUAWWg5Rm4tq30ykyTDTDWNwi12QDYENiEgE7iC3orTUBFRNRCCKepEFdT4E4pK5MptxXL 715a/acMKAN1YkAFVZ3o0sTKgDKgDDQ/A/xlXfcs6Z2RIf0w7dYPk3V9IYL6QQT1hzDaAP6B FaIpXvWMLMHwyC8QW79gAm8mFvn8UubI9DvyJS9eco1TBpSBujOggqrunGkOZUAZUAYahYFc Trm1kZ7lmdID02w9sZisB8RSDwilnhBIPSCUeiG+H8RQD0zH+esD+ZtIGI5XjDjRj+m5FXDn Ic88BOch3zxshjQ7LV9+yRVZjTg1ZUAZaEIGGk1Q5ebI+/jAH+DV1fCzjVsCDB9wz60h7OIm wHRuJD1+PBIJR8v62zEUzl9TRMHFk34Z3r4SKNNzUWY5SvOOodxyL4x0PE4/Kuu7kf0o0A5s 5ouN2RCP8qLwyytHSWGc28ZH/YhnXuQJ8zxIE8a3SS9MvxfP48yPNGhQ9Fi5V2YYdfKO4Yjv IuzFhRAu9f0MG4RNAcpAOdiVLFwIYL8X5sGp1ZQBZaC5GMjlK49ypEO4VDqmp0lHyJ4O+Lx3 wr2lM+rQBR/IrnC7IkzXC9PPeNwv+B5Df/M0RFZYxO85+AdxxPvUn/AuxOef03R/4hwLcS/5 A/75WOc0T9c5VbCnHmWgRRhoNEFVqfaO4D6Bj3vAKgUQX+twbEFx8lacJqbQSsFIIBhn/aws zYYr/MEIL0Xkn/89MRjj+wPxFVkDcUzkxUfiIl80/byVAoiK1zMVP1z2s+C2XWGd4LsJwE2X wrMMJ/IFmfFd3Lz/Fod2c4dYCkcKQN/PfJE8LKdC4Plx0TJ8UVmRB8Ixeoxl4HilcyKOaaAg KUB9REQjz5HGuoQDx2waxlo/RSVEJN5RUj4fFZ+JzSAXgFKISTVloDoGnFzspYS3oGaH2kpW pivZ+HxlldNNk6w0uG4Ix4y0w2eiHa7HdhAw7XD9tsdnoR2uPy7c9uJwkvY4noP4Dvh8dESa jsjjiaKMiq0tK1cF6SqZDdNFfr7tfinO9xddlE33L3x+luKD/BeOL3XD8ufsdbJ4rP/lDofV lAFlIBEZsJ/txqybV2ZuRDvMiLibRtzFEbd3xMUEvgPtEOroh0O4u1DfhLIj4ZIccXCf4vhV qNT4LnSFF0alQ4yvcDN9P4aX0hgPjeK5eIin4QbqpWUcj/McuIHiXippSJiGIbE0FOSlxzG6 6QbxuNGl4abG9GkQK56LktIr/JA+1o9Ro3TmQ30oj+hPY1rP9SWSf8zx03nnsfGROC8f4xj2 y/DdeHHx06DYVmYYxUSLOVqHrpDyUjw4u3TtJqF0dHoauoAu4KCjg3EOj6X5x5jOCzMt0vnH /PT0e+FAvD0eL94JhbzzevmciB9xXtgeYxjHbBzzxAUuBH4ivGMR14at6/ATE0jj9T7jYMjp uTzuhSNubNiQORrcoN+LIr3x4hnn4hf1RDkGga2frokTFznuemkxUBsOy5WXXy4bpMlLWY6U ZIakDJ/tcryHxsVFb/CBZG35ufU/A9wLyXj7IWWiWZX9HCXiMX+/JOvPQlwWCvEEj9e+pvhn 8MVDZA3OvRb1XQNa1niuvzcT31+Xh/sI1yqtRLo83H/ycOPJw9sLV+b6gqopaqVlKgPKQDMz 4N9lm/mkerqmY+BoiLmeEF8QoZh9kPRQjqRjZCgd38ozvAcTH06Zko5v536YQg1yE6qR71Pz BSHCEJjecZYREZDR44iDFojmp/gMhpnHCZQXCOPB8jeBiAeQX3Z8geint/lsGpYZicMDM2Yc sOn41ZKTkwFcY8W4Jotx/a2ji7DnxoQLcU0RBUjDgc8CXFuFSOvFYcSoEF/CCvHZyYfGXlPq ypp1hbJ2tP9i5+QkRmutDCgDjcaACqpGo1ILakYGKKAotDjJwp+Dt8e/LojoAgHYHVOCz+Wt WO6NgHA0hCMhhMHLxTx/JI6jKm65f8wbNbFpkc4/5qf3Rl94LBBvj3tuTDxHairK4zE7coMy Ko7VMIpTkQdPd290yEsPf8Tl8UrxeOp7eeAynuYP3NETCUfcv4WRxBvlYiaOCXkOXOuHuqC/ Io2fwAtXjKpxFC84ylbN6Js3GhgZLfz3PfdggyR5Pd2RgnSIlQyIFqAI4XXprhSHHCkFvKll VKEMA18lqE4ppsRKPZd+ri4MRcJlET/CxYVSgqGpdbmCPKRDTRlQBpSBJmRABVUTkqtFNxkD fxNUOBNXlHEpGRf+jq2YtkJALXEZiIg0DKx6U2L8JdpaoADg2iIKIa4FhHpUUwaUAWUgsRnQ qZLE7h+tXYIxsHz5cpk5c6asW4dxMDVlQBlQBpQBZSDCgAoqvRSUgVowMGnSJNl0001l2223 lSOPPFK6dOkiN954Yy1yVp1k9uzZ8s4778RN8O2338omm2wS95iN3HjjjeXBBx+0Qc8tLi6W nJycKstloksuuUSuv/76Svk0oAwoA8qAMqAMKAOtjwF+EeAmEjlAD2ADYBgwAjgKwIxf49ni xYtN+/btzfPPP19R6IIFC8x6661nHnvssYq4unpefPFFs99++8XNBmFkFi5cGPeYjbzhhhvM iBEjbNBzIdBM586dTUlJSaX4YCAvL8+sXLkyGNVifvZVpM/Yd+xD9iX7lH3LPtYvfSBBTRlQ BhKfAb1ZJX4faQ1bmIH77rtPdt99dznhhBMqatK/f3955ZVXpFu3bl5cYWGhnHnmmdKvXz+B yJHvv//ei58+fbqcdtpp8q9//UsGDRok22yzjUybNk1mzZol1113nUycOFEuvPBCL8zyH3jg ARk+fLjMmTNHrrzySq+Mcixmv+qqqwQCTrbffnt5+umnvfjjjjtOvvzyS+E0pLU33nhDjjji CMnMzJRPPvlENttsM+nYsaM3qvbXX9ziSATCUF5//XXPv2jRItl33329ETfmY91oVbXHO6j/ lAFlQBlQBpQBZSAlGGjWEaoDDzzQ3HTTTdWO4kAMmcMOO8xgfZV56aWXvFEijgRBMJn09HTz z3/+0/z666/m8MMPNwcddJA3gjR69GgDoWY4AoYpRW8UjCNOH3zwgZdv8ODB3jkh6MwWW2xh MEVoPvzwQ5OdnW0guLxjW221lXn88cc9f1lZmenatasZN26c+eOPP0ynTp0MRJWB4DJnn322 2X///b10F198sRk1apTn32WXXby6MT0EnIHg8+Krao93sBH/4WrUEaqU+EhqI5QBZUAZUAaS kYFmFVS77rqroaipyjh9lpaWZn777beKJBRGzz33nCeMKHLC4bB37JtvvjEbbbSR5w9O+VFQ UXitWLHCO0YhZgXVlltuWWm68ZlnnjEzZszw0mHkq0IoffbZZ6ZXr17YyaHc3HbbbRXxTLh0 6VIKF7NmzRpjBRUFXgjb22KBvVdWUVGRufnmmw2FYFXt8RI24j/WCeA0rU75gQQ1ZUAZSF4G dMoveftOa95MDHCqjovEYw2CRN59912ZP38+todyvek4TssR3333ndgpth49eggEipcda7Gq /IXggAEDBOIr9jSC9VoyZMiQiviTTz5Zhg4d6oX/8Y9/yOeffy4QSsLpvmOOOQY7vYcE4s6r j83EOrRr167S9CDLHThwoGRl+RuJY+TLW6zOvNW1x5aprjKgDCgDykCUAW6OqKYMKAPVMMB1 SP/+97+50r3S5pa3336798s/ih2MLnkihqKFtmrVKmnTpo23JokCpyHGX/stWbKkoohPP/3U +wUg12utv/76st1223m/6nvrrbcq1kbxF4k///xzRR6ulWLdKA6tsdxly5YJ12hR8GHK0FsX tuOOO1bZHptXXWVAGVAGlIHKDDTsTl+5LA0pAynJwLnnnisZGRmSm5srmLrz2sjtDt58801v wTlHefr06SOYwvOO4dd5ntDiCFZ1RhFWm/2sDj74YK9s/HLPE1annHKKYH1URdFcnI41Xp6A 22GHHbx4rNMSCq/ff//dC7O+I0eOrCQIKcZY99dee81Lg6lEb8Stvu2pqJB6lAFlQBlQBpQB ZSApGOAXgWbbNoFLhuzap7Zt23rbJXDLhLfffrtiNRGm3bwF4Rit8haX33rrrd4xroXCCFdF OvyKzvTt29cLc80Vy8GvAL1F6RtuuGFFuuAaKowueYvSe/fubSCCzP3331+Rjh6MMnnrr/Cr wUrxp59+usGv/QxGnAymE83UqVO943YNFQPcZoFbQmywwQbeOaZMmeKlqao93sFG/Id+1DVU SfGR00oqA8pATQw4NSXQ48pAAjJAQVXpXX4IN/mrZ6AjvPVMXF/EqbNK77ZDBTiCxFEpCJ+K 7RRq4o7TbKWlpd50XE1pOfLFsu16rJrS8zinClevXi3cBLSqfDw/FsN7ZQfLrE97gvlr49dX z9SGJU2jDCgDycCACqpk6CWtYywDLSKoYiuh4YYzoIKq4RxqCcqAMpAYDOgaqsToB62FMqAM KAPKgDKgDCQxAyqokrjztOrKgDKgDCgDyoAykBgMqKBKjH7QWrQiBrDJZqXW8peDXB9VldV0 PF4+rn/i3lRqyoAyoAwoA83DgAqq5uFZz6IMeAxwg1DuaUXjO/i4SSd+3Sd77LGH5+KFx96x 2hw/8cQTvXf2cbNQ7jHFrRvwCz5PSHFvKbwKx1vwXlGgepQBZUAZUAaajAEVVE1GrRasDFRm gL8OvPzyy70XHfPINddc422gOXfuXG+3de4H9eSTT3o7ntfmONOwvIKCAu9lxngdjeA9gDJm zBjB9g7eS4/5UmY1ZUAZUAaUgaZnQAVV03OsZ1AGPAYodrp16+a9moYRfMVLz549PVHFMF50 LM8++6zwFTS0mo57iQL/uNknN/kcP368F3vGGWcI3kHo7YQeSKZeZUAZUAaUgSZgQF890wSk apHKQDwGsKmntx+UPXbkkUfKJZdc4u1ttf/++8uee+4pe+21lz0sNR2vSBjxsPxXXnnFm/Zj VPfu3T0xhRcvV3qvX2w+DSsDyoAyoAw0nAEdoWo4h1qCMlArBn755RfvVS828XnnnSeffPKJ 98qYq6++2nsv36GHHiorV670ktR0nInuuOMOb4NR7ue09dZbe2VwlMoa12cF3+ln49VVBpQB ZUAZaFwGVFA1Lp9amjJQJQPcRR2vnal0nIvRueaJLy/+7LPPhKLrxhtvrEhT03EuQucu50Rh YaEn0Dp27FiRv3///rJ27dqKsHqUAWVAGVAGmoYBFVRNw6uWqgz8jQG+DNlumcDXvWRlZcm8 efMq0g0fPlzOPPNMmT17tvfrvOqO20zZ2dnStWtXD0wfa/wlIV92rKYMKAPKgDLQtAyooGpa frV0ZaCCgS233FL4iz4aXlrsrWvir/D46z9aUVGRjBs3TpiupuNehlr8W7BggWy66aa1SKlJ lAFlQBlQBhrCgAqqhrCneZWBOjCw6667VggqZnv88cfl+++/9371t+2228qQIUOEv9Sze1HV dLymU3Nzz7y8PB2hqokoPa4MKAPKQCMwoC9HbgQStYhmZ4BfBPgL1TZAW6A90AHoBHQFxhpj 4CSWcY3T5ptvLlOnTpUOHVhdEdaT2yPk5+fLZpttJmlpaZUqXdPxSoljAmPHjpWPP/5Ynnji iZgjiRPUlyMnTl9oTZQBZaBhDKigahh/mrtlGEhKQUWqHn30UW+R+JVXXtnkzI0cOVKeeeYZ bwf1Jj9ZPU+ggqqexGk2ZUAZSDgGdMov4bpEK5TKDJx99tkyaNCgJm/i6tWrhaKNr6NRUwaU AWVAGWh6BnSEquk51jM0PgN1HqHiwu+wWy7lJuJWhBFX4XcDfj8+mJ7+8kgZzFNlGMdcTOWV G78M3884v3zms366weOeH+fghKU9Fs/lVCDTen+V/H4+xnvHI2msn13BY9Zw2DMbZ6dKo2HB Pld+GkfwFwn4/mg8fTzGP9+PMP5CTggIukF/SO4dPVpk/U5vS7pTJOlp6yQjtA5uiaQ5xRIK lSBzKYopQ5lhuOWeSz/hgmC6aZGwFx8qBQOlYiJuuVMmphzhNCBcinIRLimV8oxSWfdXqTww F+kDhCCgpgwoA8pAfRhQQVUf1pItz/Dh6TIAa47aAplAGhACHCCjNM1zyzMzJL0MC3gcrE3K 4PokH8ZkVPhtHF3mDYbj+Q3OFJLK+RnnBOIYjpc3GMdzVZXOoEUSqaNBuQZpw25Ou5z2nqCh iApD4KgpA1UzYIpxLD6MrIsec9bh2i3EwrdCXHNFIiHfzzgXcQ4QSivEhYd4KRDHXSPhwrXy r0n5KEMvwqo7QI8oAynBQFMJqmC5vv9o3Ipoy4f77sb5vruq2JF23UPSuQS3pVI8OnNC0r7M kXVhR9KyQ5IF1ykNSWlbRzLLfX9ZNtwyPKpdlJGB0YpwCDrAd4VuOZAWEjeEh3XEn+bA7yI+ hPhy+OGGEGcCfh53Ecd4pvGOR/LZeE8QMJ/rCwGHfoqESBxdKwDopzBg2gp/REDEhvEV2kvr Cwnrt25UvNh8QcHhnaMKYQIWSXtrN46SpONySMOIieei+/0w4ir8oYDfj2f6ysf9MhjnH4sT 9i4tEI/uZzqeu7KfcX65wREcluelRT354QgeqzzKg8vdG/XhGBD+qvAzjx01sn5eB8xjDUk8 s3FMT4uGIR0wihUdsfKHtBiON7oVTefniY6uccTMH40LupdceqnIoM7PSZv0dZKJEanM9DJ8 pMskM80FaSAuxApFxH2ca9x+HoyJfEYc/FDBE9gQ2hTbTiYaA1FvfL/3BQFxNux4P2xgk5vO OOznCTFnDc7LXVYtEJbViMPW+KE8zzUu/Stx/1kpTjhPimSljP6Wok5NGVAGEpyB6J21oRW9 fsT7uGkc0NBiNH9TMGD8KRJvSiQwPWKcylMolY5XkcdP40/BVEofKJfxdnrGjUzXBOPoN4i3 aWw5JqaMYHwoMr2DeRtv6KkQMzWritNk1bp0uG1kdXFbyS9tJyVlHREek78m3xNMVjxZodAU 7GqZ9Wcg0i9HowQICooLT2wUwMUIkJQAvHabcnTHkVOHt8HvQ7Mgu7Ig2bIk3c3GtYldUp0s 36UfMCZbjNMOKrUdrt92ULxw3WhYECc8bvDLUwc/4zQAXGNyPGWLQuppRSjjL9TlL5z3L5Tp +13ECcIOXGP+lF/zFsnYGZzCVFMGlIEWYIDf6hrf7EIMluw40a+0XjjyvdZ+leVxz4+vr15a uAxX5cc4Om4gKBOuzUc/7mxeXND1HtiRY554YBrcnB0KCe88FBSMowtE4q3fy890iKff4KHu uYEwb/gVx0J+GgqDYBzTMK9Na8NMZ4WCk+Yft+tCmIbHKomMiJjw4uCnS6SXI53Lc2BdSTkE R1lYSorCsnRuWMZ6bcOpU8ow0uiNWsRum0Ch543ItW+TnVIN1sY0GQNGnp5gp/ua6iSOXLkL tvbI6Chp5R0wLdgBtyy4TkfcfTrhftQV6IJ7Uhd8nuECDrf/iMSJ0xbHByJ+IOKj5g3eMYhI xm/S3cgNI5ajjIUo60/E/YnyF+JcCzH4Ph/3hnlyx1fLowWoTxlQBhqTgeDHszHL1bKUgaZk oCpBldD7UDUlIcladgKMUCU+decNby9dSnuISe+BaVC4hPSAIPNdR3qiEX0honpDWVX/JdkY rOdy5iMtIPM8OOZXCRfPlNu/44iXmjKgDNSTARVU9SROs7UoAyqoWpT+xju5CqrG4xIlhTAS 1hNr0PpiRAtIo8jqB39/CLBB8A+Cv3OVZzRmFY7NBH7BaPdMLDOdKeGiqSq0qmRMDygDlRhQ QVWJDg0kCQMqqJKko2qqpgqqmhhq5ONX79pZMjIgrso3gP6CwJINMWI1BAJqSJViy5glqMVk YAqWFkzBb4Amy50TFjRyzbQ4ZSDpGVBBlfRd2CoboIIqRbpdBVUCdeQVw3tKNoSV6wzFWBdE lmwGsbUVRFfHOLVcBhH2LfCNOKGJstBMiqxFi5NUo5SB1sGACqrW0c+p1koVVCnSoyqoEr4j HRm1M0a0Mofhx0DDILDgOtug1uvF1By/LjQYxXLGY/H7OFmz+BtsmspfaaopA62GARVUraar U6qhKqhSpDtVUCVpR1696yDs/7szxNXOaMEuAEazMK5lzRjsneV8hSnCcfjx9Cdyy9fT7CF1 lYFUZUAFVar2bGq3SwVVivSvCqoU6cgLd+ggndvuhCnAkZgiHInpwi0htqLPFyO/Y4TrLYxi vS1fQmhNmMD9xdSUgZRiIHrBp1SztDEpzoAKqhTpYBVUKdKRsc24Zrfu2G9rT+wKtzfE1QEQ V70CSVYi7j3sj/UyxNWnKq4CzKg3qRlQQZXU3ddqK6+CKkW6XgVVinRk9c1w5PoR22N06jAk OxTiakg0uVmBqcGxmBp8Tm754ttovPqUgeRjQAVV8vWZ1thfq8ENDGN3SteNPZPs6lBBlWQd 1hjVvWbXjSUtHW93dY7D9OCm0SLNLLzw8Slxi5/Vva+irKgveRhQQZU8faU1jTKgI1RRLpLa p4Iqqbuv4ZW/drct8ALsEzBKdVJgWpDvI3xBwuY/cvuEnxt+Ei1BGWgeBlRQNQ/PepbGZUAF VePy2WKlqaBqMeoT68RHY7XV4OH7Y8TqTAirg1E5fsYxS2g+xmL2e+TmLz71wvpPGUhgBlRQ JXDnaNWqZEAFVZXUJNcBFVTJ1V/NUltuyZCZcTEWrp8OgdXOO6cxP+FFz/fINxi50l8INks3 6EnqzoAKqrpzpjlangEVVC3fB41SAxVUjUJjahbivSYn/WyMWF2IBuLFzzBj5oi4uXLLly8j 5Hpxifkv3rM1Xlxi1j41a2XiNCteXJxktYvSDq4dT5oqsRjgdVvVovQuOPa6MY36OUms1qdQ bSKC6kg0aSWwGlgLFABFAHfa5n5FydiZ16Pe3FGcv2w7H3gQ2Av4HLD2NjwfARMBviuvD7AU sHY4PE8DPYArAJZ3KTALoNnPQZkflF/hbg6Qt8xIXNDhVNp7wYik8J+1TYb0aIcF7GnXob4b +3U2WFvlXC03j38/QdrAvrDP01i/raI9bsPqNi8DwfuI9dON569XzfhQUlMGkpkB+4Ggy2+s ifytNZl5bsq6234L9mVTnq8lyqZYfADYCrACyNaDu4hTDFFAPWIjI+E34RYH4ubDb8XSbvBT IMV71x5/PTcTSH57bBL5elaOxnTf4D1OlpBzA7QLd2Z/D9sxfI4XPV+OEaspLdTQoHjiyDnD 1rV+Vi2YjmG15mfA3l94Zt5zbNj66bKfbDy8dTMVVHXjS1MnFgP2wqfLDwNRnlhV1NrUggH2 me2/YJ/WImvSJPkSNeV6oIuAu+PU+iXEcaTOCqoM+DmidCxQHyOPqWVj+dn+YowcvSmEVfdz PWHlyJ5iQpPkhhFPS7jommbebsGKJCucKKSItIBrj9m07BP61ZqPAftZsPcW3mvot/cd67Jf eMyazWfDNboqqGqkSBMkAQNWSPGD4U0RYSpJb1pJ0HGoIm9a7DP2nb2xwZuS9k+06mvgRWBx TAu5JugGoCuQB4wAuH3AZ0B97ABk2jKQkaNcbwXCyesdO4O83CcXD39GOsgo6JMLED5N0tse KaOG3yzL8u8Xf1SrqdvIewxhRRSFFMHRSL3/gIQkMN5/OgH2/sMqW1GlgopsqLUaBnjB8+K3 gopTAwS/1XMapAPAUYG2QBbAb/38EsEboFrzMcD+oWhi3/DBzvVRhQDXS60BbL9ZQcX0db6Z IU+iG6fgxgAcoTo+prJzEJ4KHAIwzRHAWICc1MeORibybG0VPKkhqGyL7p1A4XK5jNoZo3qZ o73tFkLO3dKjw/9BWF0gt04YZ5M2gWsFkxVTvK8QvMc4uoazCRhvgiIjX7y5QTTvQbZPeSZ+ 7hiu032IF4Ba4jAwHVW5E+A32AnAQICvabA3RnY8H0jdgUuAXYE9gKAxLx9IJwK2vL7w3wrQ +A2KZm/Ut8E/BXibkTHGc2XHxCVKkBc6YcVUGH6CC3JZ70zAtpVp+K3WxqmgAhnNaLaP2AfE OoCCii77in1m+8+KKtu/OJRSdhNaw/VSw+O0yk77PYNjhwJHxUlT26jTkPCX2iZO6nS3TpyH +h+Cab99cUe4D4/BwRBXn2J91avYdf1Sue3bRU3QPgdl8j4SFFS8v/AerZZcDPDLNvuTZu87 9tlCt9amgqrWVLVIQo6wXBdBbAV4870aWA9YFjnID/SBwHGRsHXugoeg3Q9wxOZMBiLGb8Uz AC70TAaLvej5ECb4sObDmQ9qK6ZsPLnht0fG2w8PvGrNwAD7i/3Ab4HsI4qooKhinzHe9iMF WLCPEUwZW4uW8HP7IPBHTKteQZhffPYFyMlEQK22DNw8/mM5a5vNMULFL5s34FN+jKS1OQCj VbmYaL2vCfavsqKK9xTeWyim+HBWSy4GbJ/xnsN7j0WdW6GCqs6UNWsGiqArgKcBTgkEDT8b 9n7FcxjcxyIH9oLLh9ankXCqO/YDYEUTb2y8pu11beP58KagYrz9VgmvWjMxYG9QHIWicAqK Ko6+2lEqK6qsoGqm6jXB5LcWAAAgAElEQVT7aZ7FGc8GRgLvBs7OkZTvAf4a8GWA13d9rRMy donJzFFBCrXUNX/t1F1y3e4vSSjEacAj8Ym/W3Y3p8ouw8+V2yZ83UiNjxVTFFS8xyTqiH4j NTsli2Gf8Z7D54W9V1m3Tg22D546ZdLEzcbAQpyJ6y14g90vzllfRNyRgBVUR8D/GkBRVVfj mqN/xGSiiJsUE5cowaCYYnvt0Dtdmp3+403u/9s7EzgpivP9N/cth+KFxyLgrSh4YhCIGhPx Fk0gmEii+f+jEohRI55BMMQrKhHRKNEgOYy3xisqIBg1ES9iVCIEEA2KIIgccvbv+fZOQTPO zM4uy8LuPu/n892qrqqurn6qu+rd6p6Z4EzhcNmhQp2qtTA4MWClnSom97BahTNFP0IY2DbG oVA1W6xxXgMFzlO2cU/fIViB3hh7KcfOZyttTI70mpd0zSTGzj5anfqm7niNn/qahbrxpOjK nmOjZSsvjm54aV4lnHTaqWKM8QpVJYi6GapghYpxKYxPzBEVeopRoZ02wwnXlkNO1Yn+SjCo ThR3CV5M5XEcK1VPCiagtmK+aC+mie0EjxLmitPFCwJL11eakv+RH8fMHuB5iXVk2HELC4Nj FFalwn+IDGphcCMtkHamfN1XbWcG5zf8FxgcJ0KcKpypEJIWBrfgiCnJZgUqqMDAjo2iljtd IsfqEs2TmjzjRVr7uyJ6b+Joja5MouU1xg/GE8YWxhtWOJqKFhkm+aV0KVENLPNh8CPV1C8y sGLOEw3Go/DPXdH/2HmFSqpt4UbHDhKjxESRtpnaYAXpBDFbUHaSqIjN0k5fr8iOm2mfMEkz uDEoBieJdLYhOFuEwaGiXCirqK0KFKBPQn+FvglOU3plKqQFR4p9bFZg4xT4zXSNi9OH6tOA 46I6jUbqMeBxGgF+E+3Z80fRlfEg/fDyhAocIIwj/GMXxhnmUxwsW/VSgD7DiaL/NmqesENV PTr+CTXzx+LSHM39k9J47DdT3CdqyyTEeTKoMfkGIy1MxkzOaUeKgS8MgnaogmJVE9IvgdA/ wbEiDP8JhrTQp+xjswKVo0DppwF769OAfILy13Ks9tOQMD66oueDUbz2omj4pJk5D3R5z6u0 hjomum7ih1n5jCOMK8GpCqvhWcW8uYUrEPotOFNhrih3s+1QlVuyzbbDYB35jRxH/4vSfin4 Ph8+rVdR42Jqk2PnhUrbUie20K70BBwm7DDIhUEvOFOcoh2qHB29CZNCPxECfUSIA0U8hKHv Qjll2axAJStw9YRHo4Edn45atrtA37Z+afLiep16J8ixuk1fUHNNdONEXqcotSHd2yZlGkc/ iIb0PDYaMfG9kJUKw1jDGOo5NSVMNYnSZ+l/vivcbHd+haWr8h2n64i8z5S9SvWx0l4ROwse /1XU9tSOC3Ls3FJpi3OkbwlJTLzBmJTDZM3EHBwoBjssbJdu+e/mUCDtKAWnKvRZCGlXutzm aGdNPibjRHMxU/A+Ztq4V4DV3aoyPo24KHOwdHzTHr/0MeCI6OIjfh81ajhCo0N/OVaD9TXA P9CL7NdFK1eNjK77+xdR/foD1BDeydxFb0xNji7r3ju6ZvKrmcaFMYUwaMfEbKteCtBnof/S fVrus2BnmxWoCQqEG4FzyY6H8/P1HpSo+vB6HXKJ+EXm0DhNWNp5SsdLc8v+209F+JDGLami FyneObXNPxo3ZbZPUsg+OHR3i78JjPco+P6iHmKGGCE+Eli++thnTFJi/Z/bFH1JHCl+tD45 iX1ff3H8dxfniU5igrhR0B7sB+IUwcuxPM7ncT+PRAu1r1B92jX5xYBrFLYTHwjqO0rMEpwb 54uxws2rBd9iYxPY4aoTzfnnra3gQzZofE4qfrLiVW+Xdt8/qlfvV3Kqwrl/FsUxX7twlhrT YV2DYn0hbbzmVD0epN/oE15Gx0HlOwNxCFnlf9AvpUuFamCZl9J5ZeYzgWPP4gHjFPcf7yTz z0UsijKvUBUlkwtVAwW46NMXfi7nKVdaNTi1GtHEq3UWOA3Zqx/pPivPie6twjgeOEF/ztrx +9oeLhgYsY9Lg8RZul3xywROxDjxbYEDhMN3kNAnwaKuYoLYR+B85KtvN+XtKy4XwWZnIj0V MkA/ndkm4PyZfB8TzwnaMVTgXFwsaMtVGWjfrWI7cYfI1z4m9Xz1KSs53qMKWdl+WXQRc8Uw sbMYI3BiaOumttd1gKMzB0HjhoJjfzMVV3Qz2C8nT9VR+RLQnnrER58cKWcKjTa0OvyUVd2/ RpccOSD61SR0Z0xJU3fDHbxVDRSgz9J9mB2Pq8E5uIlWwArUQAW20TnhADBpszJ0qMB+Is5O YqWfVu2v+JviP4L/EIMx8bNikbYztXFMOkHx4wSrTlMEjkcwBkOOncv40MbPUhnsd6eoJ1YK HIxg8xThmIXqO1757J/LxirxGzkyONdXUuk9FOdRO4P6XWKwCDZQkedFofYVqo96WP3C8cRG i9vEdYLVoe5ikOgrsBPFeDFGfCpeEJ0Edn6GPygMDuRQxd8T9CP9FuwpRXCU6JuZgn2xfcUf RXvxjlgs6JMQ57jZ1k4JzwhWEB4SnQW2g/ir+Fxw/J4C21/8SQwR08UDgn04l9ki3f/azGNX 9Oqhl9c/EXFOrui5Nrr4a9SFw9tBHCh6iT5CC1S26qAAfZXpM/qOPqQv6dMWAoef+7JoK1fh omt1QStgBWqrAv9fJ75MMLH9TvxWYO3Frkksig5XeJZg8mGVBkeCwQvDsVmVxNb/OVjRPddv JjEcgp+KCVnpTLSrBRPpvwQrUq0FxmDJ5BtshiI4DLuIJWKOCMZkvLsoVF9H5VPnZPFPcZ4I Rvr3BMdjlYpzwNgnuw1tlLaNuFKkHTQcHuou1L5C9WnXZFXuUYXbC3Q/V9wguomXBY7jtiIY E8t8cVQmHJfJwLG5OpOGE8Tkw+OxU8W3BfUGZ2c/xYeIAYJj3SKaCiapLuJD8WuBI/XzVPwq xbONY+G0Uff7IjhdpNO/JWK4eFBwjlpBSr6Lj0mxn+C6mSRoA228XtCOwrZ8xbtyi1rjGuUt 2LjBDdGFX7s4b74zap0CdqhqR5e30mkyyDFw26zAplSAibckc4BRCvtm4tkBkydOy/3iRXGk wJiA7yFSQdtN+zUXj4hLBBPxnwVWIj4nkrE5CilbItLp2kwmfSbnQvW1Vz6OIOdyj7hanC0w 9vtYDBQ4bs+LnUSJWCyCfaQIkzbH+p9YKnA+bheHChyIEpGvfeTlq09ZyZdPrlV4mniGBNkh YrzA8UT3p0QwjnOZmCoGCcriqGCvCtJwbCiHw4JT9KngPLqKYJcrgsPDNYAOnUSwVYqwirhc zErFcbTShkOLE/hzQV/9QjwqqOsIMUIsFA+It0VvgX0hLhD/FJznRMHq1hMCjdNt0WYOa9xw gB75NRB1cuRq3TKT3rTBBdHPug1Tmdzlcu7sxJqqQP1NfGLcDHcL/kuoTGunykYKBolgDAw/ ChuZ8PsK1whuzPMEN9IEcaNYK7CTBAMD27T1bwIrVN9Fyu+clCr985qCm0QjwQCYttu08ZIg 76eih5ghGAw+EtiBggGAgesxwQTAIIXla1+h+kr3LH334zvaYBDhWAyO24qhgoFpUxha09+c R7ZtquuBgZj/lhnAbZtXgeE6PPfRXPGiuF4w6WYbk3KwWYowQT4XEhRyjwcHYAfFV4j/J3AC DhD5jGO2EXGmAPfRP8TWYplgJShYM0WmCyZ28tOGU8N9Wqi+QcpnIuVY4wVOFGPJXWJHEdpA Hb3F8YI2pI/VRNurBA4Dto/4q5giGBc+E2iR3kebidNF+7bLysuuL4xzC1WO+uqKM8Q00UN0 FP8RwV5WBI2xD8V8gZ4Y41wwNLtSnCoWicYibYw5wZYoQrvKayXaYab4MrMjx8R5+YZ4TywW wf6ryLbiHcG1F86b6+bfIhjn1iBs5AnryGE6J0/eV5ObNeob/eyIttHt/7g+Whqk+2oxp9R8 Bepv4lN8XfUfXYnHaKG6+oszBQNB2npqgxv76VQiN1Vz8Zh4TlwmcCbaiosFA8rtgnQGp3Hi 2+Il0VPkqk/JFXpJ9Xrtd5C4RHQVEwSDJwP3s+J3gmXwH4uTxVGiUPvy1bdK+2G/EdNFb8GE xDlfLdoJNGBwCs6jopVmnNv3BJpnW2VfD6H+bop8HDYcblYF1ujo3xQ4LtxLY8WuItu2UsK8 TOJ+Cv+UVWCBts/NpOG4fCgeFHEmLV+AM4/TwMSKzRLLBNf7ByLdlhJtU450xpY24jOBtRdM xIXq66n8twTOCjZTUH9LwX0wXmC0eZbgnBqKA0SwEkVwaJiJGdO4by4SD4hghdrH/ZyvPvb/ u2AMoF7GlIfFVeJa0UUw3qSNfguGHvUEzle2XaqE1qKTWCweF2lj7N1Yw2naVtAGriscIa6p CYIxjX4Ox9lD8d8LjLIVtyGHtNEXfY6J4joNozqx+kthpLBOXR0/sx2vbayjNNYjwUbq3SZR vTqton4H9I/unILONiuw0Qr8VDW8LWaKCzO17avwj5n4lQoZIJ8U/xM3i/oC6y7CzZAk6M/u 4vKwkQl3VHiTYPANg3EmKxm4vxE2UuFpir+S2u6hOAMbN+N94mci2K2K3JnZGKswV311lD43 UyY7OF4JYf90HgPCSrFzKpH2HyOOFX9PpW+vOIMEA1u+9hWqj6oOF38gIvuWmCzOE2g8UjAY PSSCMSg/I5hMSO8ssGbiLjFHMIgdIrD9xd3i5+K/4jXBPkw+bH8ufpPZph0DxUSRvh44h2sF OvxTnCVoxxTRSgTD4T1F0F/Dxf/ER4Jrg77AHhEdkljp5MFATJs51yaZdNr8giD9HrGVyGVM Prn251rg+ubcHhTbCewCwQT4FzFDXCz6imniLXGQqE3GdcR9gDUXnwiuZe7bYQJbIZiQMSbC pYL+wY4QByax9X/oR66hXHa9Em9NZfRUnPuzpagnrhYPCexC8bLgWuok3hdHC4xrkHzsDEG7 GZ96inz1jVLeWIFxjtT9HdFQcI0GHQ5W/AuBHu0Fzt3uoqlg/zsExj31S0F6oLHiWL72FaqP /bYV/xC0IdtwxLi3gp2oCH1DX3BvcS0H7UYoTtuCPavIDzMbtOGz1PaHiu+VySOYJg4Thwvu LYz7jDEFS8fZRn/ajXEP4URhZ4v7klgUva7w9EyccfVTge4c418iGNdHut2ztH1oyKxgyPXD sVoIxoEOgmu2l+gjqsP72G5j6ftxcabP6Dv6kL6kT+lb+pi+rnJjIuUiZkLEOZojdhfpG2ic theJHmIf8Y44UWDdxG+T2Po/1DN5/eYGMQaHeRuklDolHONN8bQIA8jPFb9dBNtJEUTkhp0i jhLBfqrIxMzG3xXmqm9HpXN+DwjOmbpbC2ywGC9oNwPgeQILA07pVunflxSQv5WgA4MxSPw7 s5GvfYXqY9dfiKDtRMXpH+wFcZxolIkrSOxF/b1FMDBdKzguxvk/LBgcvyM+E20E/bpKsA/9 /JB4XDQUaMBxdhBdxBcCTb4l0tfDT7T9lmBi+6ZYJjoKNOVYGBc16duL88WrgjbuId4VZwns Q7Gf2FUsEScI2swER/9vJT4VOD8lgmvtEZFt+fbnmAvFMYKJkz5/UmA4CuTR5pPFWoGeh4hR IpRTtFZYb50lfYb2b4thAkOnEF+h+FOCvl4krhDB7lfkxrCRCcvjULHLvQLHfraYI7oKjOuT 4+LsLBU3iGB7K/KxYD/adJQIlq++3VTgDcF1TH30dTOBfU9QF3krxWARbKAi3BdzBfu3FNh7 grEpzWtkyAq1L199pXuWjnUPawNtrxa/FPeJO8V2ItiJirwipgnaPk8cJLARgv2CnaQI7aef ud5vFuzTSnA/cv8Fo77DRPr+5zqZkCmQjpPE9dEjk3eCQrSaLtDyAIGdKtAc/T4RaIBxDK6r YNcrkm73LG0fGjIrGNqhqiHumPqfe62P6CUOFB0E90QLwXixWRyqr+vAXNThYsdpYRJL30Dj tH2LCMaAc0fYyBF2V9rkHOkkHSy42dPGzc0AyX6jxGJBO0aL60SwOoqsFe3FfBEGDEUTYacQ keWr72vKWyj6CwYCBpRnBMb5Mbigx7ligThb0FkzRdr+oo2L0wmK9xOfib6Z9HztK6s+JoD9 xPZieqauegqpr6lg/8sEtrtYIxqzIWsimOBai9WiRAQbrwjnTb9SF3Vi3cR/klhp25/KxLso xPHaOrPNfkwa2Jviu0ms9A/Xw97icvGH0qTkP9PnMnHKD8jECc4XQXcGcM6Xc3pEBKNvuVno g3+ERIXbCCa5Zqk0ovn2v1R5aceIG44bkWv8JnGXCMZ1E86L850eMmpRyLVzoGiU55xXKJ0+ 2FFk90GeXcqdzIDYQeQaEHdROm3MNq7nPUX97Axtl1Xftjn24dh7CO6pbKO+3bITy9guq31l 1Ud/dBbtRZ0CxyKPunLpkN6N80LLYLk0CHkbEzKxca1kG9fO/qJ5dsYm3qZfaRN9yFjAdcb1 3ksw3tQQd6PmnwZ9lekz+o4+pC/pU/q23A5VWTeM6izKmGjHikniU/F7MVxk2/upBByMbIeC 7D+LfQUTPyf2tsAGieeTWO4/3HCIg70oeovjxTIRJnRFk8FtlcI5gjwG9mDcoGECzFff7SrT RoRjcb5M1hyDNjIYkYcmDEr9xKUi3QZtJuc3g4iMge6PYj9Bu18WWL72LVdeofo+VH47gcbU DdzopLcUQ8RPBFYiKPelwKh7mOgqGDj+KYKhzxOCdn8i1ghsicg1aZA3SywgkmUl2n43lcb1 g9E36FlfnCz+JLASQXqw/yrSNmxkwhKF6TqnaBt+JdB2ngjGuaHh0pCgsETk2v9Opad14NzZ LxwfXYOtVOSdzAb6cFPWNluoE4ay7H9lFdiI/C+0L+SyD3IlKo3+Cg5/dpGK1LdWlUzLriiz Xai+PLtUuH2hPhzZt8JGgZDxi/urLGOsSGuZvr/K2rc8+dxTua4V7sGp5anIZa3AplSASaUy jEn6KsEEc744U5wksg2vLxgTHBNTtl2rhHPFr8WMTJxtVijyGcfvlcpkQJglmMhnixIRrESR /4jVgsFgVxGsRBEmw0L18R/sXiLYLEVwfBhceopWIthMRWgDx+HcccSCtVfk3wLH4S9ivkCT l0WwfO0rVB/7Pi36Chyd4eIJ0UDcLx4Vd4swcRBuK+oJjHL9xecCjWgn+bCTGC0wJouNMY67 Q6qCYxTfWbwvZomvi6PEQwJDK44fbA9F0lqRjjOUrrOTtrsLzuVvIpwH4S4Cpzpt+fbPPjbO 6lIRJp2N1SLdhtoQ55pcVhtO1OdoBaxA7VGgbiWd6umqZ5RgdeEpwapA2nnQZmKn6i8ORHNx mnhRYExuwQF7Q/FJgv+kmAiJA45JPluujHvF8ZkCByvsKmjL46Kb2F00FZeIlwTG46GzBDow +eJIkFeovu2V/7zA6aonzhfPCCYIdLhFYKx8Ud+Dgv+uXhU/ENgZgvzp4huio7hIUB9thDoi X/sK1afdkneYcIxYhfqtOFrcI64RHI9zCPaBIjh+fTIJ31d4QibtI4X9Muk4O/8WODKFbLUy mxQqkMmjX6i7kcAJ+r1YJLD7xHUCh2mhwP4qzhSNBdrQ18+KtFHmKLGrQEv6YjsxQfQSXGcY x50oYoFzdIrA8u1P+jGCerETxXOC/W3lV2CYdrFDVX7dvIcVqDYKLFmyJFqzZk3SXkK2bcUp gHMxQ8wSTIIvCB4PHS5YicDGCSY2/qufK54XOA4YDsacJLb+T3dFJ6/f3CCGwzRvg5SKvQTa UHXgdOE4LBU3iGDfU4S2viVWisEi2L2KkDdb0G6cN2w3gUPIPtT3pEAHbG/xsWA/HIejBDZM MDFnQ12F2pevPu2WWF39vUIw8eNYXCruEY+JI0TacKC+EDh4tP0AgeGEzBfvCPIvExj9+q8k VvpnfwXogJWIT8TvRBfxvgiWvh52VCLHQnt0HCiClSiCHt8JCQp3ErTjQ8E1hZMTHDfS9hPY aIFDjM6PiHoCGy5WCOrgeFxfGM5R+lrKt/8YlWN/ru+ZorPAbhJXJrHSP9R9YGb7EIU4rDYr YAVqjgKMrYzNLcR2ooPgnu8l+ogt6uWjDz74IJlbWrduHbdp0yZu2rRpvOeee8aPPfZYpbaz Xbt28dSpU5M6Bw4cGO+8887xnDlz4kcffTTedddd4zFjxlTq8SqjMvoq02f0HX1IX9Kn9C19 TF9vFuPg+woak8twqH4scDCYTDeFcfJ7iDDRpo+BQLulE1LxXRRvndoO0bLqQ/xcglPftqGS VMjkziPD+qm0YqL52ldMfXV0gPYCB6BRgYPRf7n6hX1wmLYpsG92VgMlBEcyOy97e2clcB7F WDjfXO1M78/qaMt0QibOOaAD51rI8u2/g3baSxTb3kLHcJ4VsALVUwHGfMaQauVQrVixIvFB tFoUDxs2LHGuVq1aVRl+SVLH7Nmz43CM5s2bx9OmTUvSBwwYEA8fPrzSjlOZFakPt1iHqqxb IzhUZZVzvhWwAlbACliBLVWBau1Q4ZCMHz9+nUP17rvvxv369YtHjhwZ9+jRI/FXnnzyySTO KtN3v/vd+NNPP03Sb7zxxnjUqFFxnz594h133DE+44wz4uXLlyd5J510Ujx9+vSkfN26deOD Dz44vuGGG+K2bdvG7du3j++9996k3Jb0RxdYtXWoTlXjD9pS7xC3ywpYAStgBaxAEQpUS4fq zjvvjO++++4Yp2ifffaJr7nmmsS3ee2112JWlHr16hXjSK1duzbJf/zxx+NPPvkkcZAuv/zy pOzgwYPjli1bxg888ED8wgsvxCUlJfHYsWOTvPDIj0eMjRs3jl999dV43rx58SmnnBIPHTo0 Xrhw4ZbkSyVtUV9XqkNV3kdPRVxreYs8lDfHGVbAClgBK2AFrMAmU+DZZ5+NtHIUaUUpWrx4 cfTmm29Gcp6S43355ZfR/fffH2299dbRsmXLotGjR0fdu3ePVq5cGXXs2DF65ZVX1rVLq1LR aaedlmyffPLJ0XvvhdekS4toVSvit6PlbEXbbLNN1KJFi0irVFGrVq3W1VFTI1XpUNVUDX1e VsAKWAErYAW2aAX0yC1q2LD09VGcpgMOOCCaPHly4vDg/OBMYU2aNImmTJkSnXPOOdHnn38e 6dFe4hCFk2M7WLNmzRIHLGzX9jDXC9W1XROfvxWwAlbACliBGquAPumXrCC99dZbXzlHnKxr r702euKJJ6K5c+dGgwYNSlacQkFWuWy5FbAyuXVxqhWwAlbACliBGqPA0qVLk9UkvdeUOEw4 Tscdd9xXzo9HeJ07d446dOgQrV69Orrvvvv4HoivlHPCVxWwQ/VVTZxiBayAFbACVqBGKaDv oIp4RLfTTjtF48aNi+65557k/ajskzz99NOjWbNmRV27do323Xff5F2qN954I9L3SWUX9XaW AnxHkc0KWAErYAWsgBUoTgEWInj/mO/oayqai60Eb13zItL9NWFFZ8aMGZG+kDOqX79+8hI7 71/p03s6vZpjvDwvO10sEIvEYrFELBN8kfNqUfrmviJlmV9KL0sh51sBK2AFrIAVqGUK8Mgv 2FZb4S/aylLAj/zKUsj5VsAKWAErYAWsgBUoQwE7VGUI5GwrYAWsgBWwAlbACpSlgB2qshRy vhWwAlbAClgBK2AFylDADlUZAjnbClgBK2AFrEBNU6B///7JF33qZ2eST//pp2Mi/bRM8mWe nOthhx0WkccXfvIOFV/oeeGFF0b6ceXk29b32GOP5Duq0roce+yxUd++fdNJjlsBK2AFrIAV sAJWIKcCLETwleMtxHaCt7cPFL1EH7HF/WZdrgbxo8dDhgxZl8Vv7XXq1Cm+6aabkrRDDz10 gx801k/VxPqkX/z0008n+fo5mrhBgwbxhAkTku077rgj3mGHHeIFCxYk29XhD32V6TP6jj6k L+lT+pY+LteiU7kKq3KbFbACVsAKWAErUMMU4Lf2WF2Sg5TzzPbaa6/kt/kyXzUQyeGKLrro omjAgAHR22+/naxe3XXXXRHfd1VbzV+bUFt73udtBayAFbACViCjAD9Dw7ei89gvGN+mzrel r1ixInruueeSLwXt1YvFnFK76qqrkp+owbnq169fzm9eD2VrQ+gVqtrQyz5HK2AFrIAVsAJZ CowYMSL5nT5Wnbp06RLtsssuG7wDNXXq1OiZZ56Jxo8fH82cOTNatGhRxBd+BuPLPo8++ujk J2169+4dkh1aAStgBayAFbACVqBMBWrMO1RajYrnz5+fsHz58g1ee8p+h4pMyp933nnrysnh ips0aRKfc845cUlJSazfC1yXVx0i6mm/Q1Xm5e4CVsAKWAErYAWsQEEF5Awln+Ljk3zF/KzM 3nvvHfFoEOPTfj/84Q+jc889Nxo9enTUsmXL6Morryx4vJqe6Ud+Nb2HfX5WwApYAStgBSqg AO9OLVu2LNLKU/Twww9H+gTguvekbr755mjevHnR0KFDo3r16kW33XZbNHLkyOj111+vwJFq xi52qGpGP/osrIAVsAJWwApUqgJnn3128h1VfB/VoEGDomOOOSa64IILkveoWI269dZbk3wO 2q1bt+jMM8+M9PgvWb2q1IZUk8qSn1quJm11M62AFbACVsAKbG4FWIjgE/KNRFPRXPDrwa3E 1uJ+vT+kwLalK5D5CojT1c4FYpFYLJaIZWKFWC3WiqLMK1RFyeRCVsAKWAErYAWsgBXIr4Ad qvzaOMcKWAErYAWsgBWwAkUpYIeqKJlcyApYAStgBayAFbAC+RWwQ5VfG+dYAStgBayAFbAC VqAoBexQFSWTC1kBK2AFrIAVsAJWIL8Cdqjya+McK2AFrIAVsAJWwAoUpYAdqqJkciErYAWs gBWwAlbACuRXwP00CBcAAAUMSURBVA5Vfm2cYwWsgBWwAlbACliBohSwQ1WUTC5kBayAFbAC VsAKWIH8Ctihyq+Nc6yAFbACVsAKWAErUJQCdqiKksmFrIAVsAJWwApYASuQXwE7VPm1cY4V sAJWwApYAStgBYpSwA5VUTK5kBWwAlbAClgBK2AF8itghyq/Ns6xAlbAClgBK2AFrEBRCtih KkomF7ICVsAKWAErYAWsQH4F7FDl18Y5VsAKWAErYAWsgBUoSgE7VEXJ5EJWwApYAStgBayA FcivgB2q/No4xwpYAStgBayAFbACRSlgh6oomVzIClgBK2AFrIAVsAL5FbBDlV8b51gBK2AF rIAVsAJWoCgF7FAVJZMLWQErYAWsgBWwAlYgvwJ2qPJr4xwrYAWsgBWwAtkKxErIx9rswt7e 4hWgz/L1J+lFmx2qoqVyQStgBayAFbACGyiQnoiZmO1QbSBPtdgI/Zbuywo13A5VhWTzTlbA ClgBK1DLFUhPwGFSXlPLNamOp0+fhf5L92m5z6V+uffwDlbAClgBK2AFrEBQgMmYSRlWi7iO TKFty1cAB4o+C/1HX1bY7FBVWDrvaAWsgBWwArVYASbjsLLBhLwqw7cVthRbiWaiqWgsGgjm XD8ZkghVaPQRThP986VYJpaKxeJzEfqNPgz9Sd+W2+xQlVsy72AFrIAVsAK1XIHwaIgJOKxM MWmvEEzaDUU9gVFmpQhpdqhQpeos9BF9AMsFDhUhfUWf0XdhpYryoX8VLd7sUBWvlUtaAStg BayAFQiTLWGYrHGqmKyZnJmogzMV0nGmWKEi3Y8DJUIVGv1EP7ASRR/hRKWdKvqMdMpA2qFi 36LNDlXRUrmgFbACVsAKWIF1CqQdKiZknCXm1DCvBmeKyRuHinRWp7xCJRGq0HCQgBUo+int VPH4L6xSBacqOFTKKp+Fji/fXi5tBayAFbACVqD2KpB2plj5wEnCoQrOUnj8hyMVnKmQH8oo y1YFCgSHCgc37VSFx7M4vDhT2e9SlWt1ivOwQ4UKNitgBayAFbAC5VMg26kKj/LCaggTNo/5 wqM+HCkI5RS1VYECoZ/oF5yq4DgRhsd9hGynH/lps3xmh6p8erm0FbACVsAKWIEwSeMcMQkH J4l0tiE8AiQMq1OUC2UVtVWBAvRJ6K/QN+EF9PTKVEgLK1rsUy6zQ1UuuVzYClgBK2AFrEAy QeMYMfkGC5N2WKFKO1JhZcoOVVCr6sLgUKX7JzhWhGFlKqSFPrVDVXV95CNZAStgBaxALVYg TLjpCZg44EDhUOFApZ0pbXqFChGq0EI/EQL9Q4gDRTyEoe9COWWVz7z0WD69XNoKWAErYAWs QFAgveIUHKcQBmeKsulyYV+HVatA2lEKTlXawSINS5crTSnyrx2qIoVyMStgBayAFbACeRRI O0zZ8bCL59ugxOYJcZSChXjaeUrHQ7lyhe7gcsnlwlbAClgBK2AFylQg19yaK63Milyg0hQI TlS6wlxp6XzHrYAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJW wApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAK WAErYAWsgBWwAlbAClgBK2AFrIAVsAJWwApYAStgBayAFbACVsAKWAErYAWsgBWwAlbAClgB K2AFrIAVsAJWoGYr8H/7lw1kOw78VAAAAABJRU5ErkJggg== --------------080402040101030305030508-- --------------000408030706030408070108-- From john.elwell@siemens-enterprise.com Mon Jan 25 08:13:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BBF3A68A5 for ; Mon, 25 Jan 2010 08:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJkPLPYewCbR for ; Mon, 25 Jan 2010 08:13:22 -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 9EE7C3A685F for ; Mon, 25 Jan 2010 08:13:21 -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-658175 for martini@ietf.org; Mon, 25 Jan 2010 17:13:27 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 7577623F0298 for ; Mon, 25 Jan 2010 17:13:27 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 25 Jan 2010 17:13:27 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 25 Jan 2010 17:13:27 +0100 Thread-Topic: Requirements - rev2 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQ== Message-ID: Keywords: MARTINI 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: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:13:22 -0000 Although the "Requirement - rev1" thread had a lot of traffic over the last= couple of weeks, very little of that traffic led to consensus on change to= the requirements list. So below is the requirements list again with my com= ments inserted ("[JRE]") where there has been discussion. Please continue the feedback so that we can have a meaningful discussion on= tomorrow's call. - The mechanism MUST allow the PBX to be responsible for its AORs and to ha= ndle requests to those AORs according to its rules. - The mechanism MUST allow the PBX to receive requests to its AORs that ori= ginate off-PBX and arrive via the SSP, so that the PBX can handle those req= uests according to its rules. - The mechanism MUST provide a means whereby the PBX knows which of its AOR= s an inbound request is targeted at. - The mechanism MUST provide a means of avoiding problems due to one side u= sing the mechanism and the other side not. - The mechanism MUST observe SIP backwards compatibility principles. - The mechanism MUST work in the presence of intermediate "proxies" on the = SSP side of the interface (between the PBX and the SSP's domain proxy), whe= re those intermediate "proxies" need to be on the path of inbound requests = to the PBX. [JRE] There was a comment from Bruno to extend this to proxies on the PBX s= ide, but I didn't see any consensus to accept this. - The mechanism MUST work when the PBX obtains its IP address dynamically. - The mechanism MUST work without requiring the PBX to publish reachability= information through the DNS. Also some desiderata: - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing S= IP service to ordinary subscribers in order to provide a SIP trunking servi= ce to PBXs. - The mechanism SHOULD scale to PBXs of several thousand AORs. [JRE] The following was proposed by David Hancock and I saw no disagreement= : - The mechanism SHOULD scale to support several thousand IP-PBXs on a singl= e service provider network. - The mechanism SHOULD require relatively modest changes to a substantial p= opulation of existing SSP and PBX implementations, in order to encourage a = fast market adoption of the standardized mechanism. [JRE] The following proposal from Keith was discussed, but with no conclusi= on (or was Adam's objection not so much to the proposal but to Keith's subs= equent assertion that it means no change to the Request-URI on an inbound r= equest?): - The mechanism SHOULD allow handling of inbound requests and outbound requ= ests between SSP and PBX to be as common as possible as with a normal peeri= ng arrangement (RFC 3263 based), as far as the PBX is concerned. John From bruno.chatras@orange-ftgroup.com Mon Jan 25 08:21:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1ED28C0F5 for ; Mon, 25 Jan 2010 08:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 dWKxwN4SiOIO for ; Mon, 25 Jan 2010 08:21:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 2228928C0F4 for ; Mon, 25 Jan 2010 08:21:50 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id D276E2AC6D4; Mon, 25 Jan 2010 17:21:55 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B85B838404A; Mon, 25 Jan 2010 17:21:55 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:21:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 17:21:54 +0100 Message-ID: <20708_1264436515_4B5DC523_20708_51782_1_9ECCF01B52E7AB408A7EB853526421410101AAB8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev2 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQOJF6Bg References: From: To: , X-OriginalArrivalTime: 25 Jan 2010 16:21:56.0309 (UTC) FILETIME=[83335050:01CA9DDA] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.25.154819 Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:21:51 -0000 If there is no consensus on adding the requirements about intermediate prox= ies at the PBX side could we instead add something like "The mechanism MUST= allow the PBX to uniquely identify the communication target based solely o= n the contents of the Request-URI on inbound requests."? > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : lundi 25 janvier 2010 17:13 > =C0 : martini@ietf.org > Objet : [martini] Requirements - rev2 >=20 > Although the "Requirement - rev1" thread had a lot of traffic=20 > over the last couple of weeks, very little of that traffic=20 > led to consensus on change to the requirements list. So below=20 > is the requirements list again with my comments inserted=20 > ("[JRE]") where there has been discussion. >=20 > Please continue the feedback so that we can have a meaningful=20 > discussion on tomorrow's call. >=20 >=20 > - The mechanism MUST allow the PBX to be responsible for its=20 > AORs and to handle requests to those AORs according to its rules. >=20 > - The mechanism MUST allow the PBX to receive requests to its=20 > AORs that originate off-PBX and arrive via the SSP, so that=20 > the PBX can handle those requests according to its rules. >=20 > - The mechanism MUST provide a means whereby the PBX knows=20 > which of its AORs an inbound request is targeted at. >=20 > - The mechanism MUST provide a means of avoiding problems due=20 > to one side using the mechanism and the other side not. >=20 > - The mechanism MUST observe SIP backwards compatibility principles. >=20 > - The mechanism MUST work in the presence of intermediate=20 > "proxies" on the SSP side of the interface (between the PBX=20 > and the SSP's domain proxy), where those intermediate=20 > "proxies" need to be on the path of inbound requests to the PBX. > [JRE] There was a comment from Bruno to extend this to=20 > proxies on the PBX side, but I didn't see any consensus to=20 > accept this. >=20 > - The mechanism MUST work when the PBX obtains its IP address=20 > dynamically. >=20 > - The mechanism MUST work without requiring the PBX to=20 > publish reachability information through the DNS. >=20 > Also some desiderata: > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > for providing SIP service to ordinary subscribers in order to=20 > provide a SIP trunking service to PBXs. >=20 > - The mechanism SHOULD scale to PBXs of several thousand AORs. >=20 > [JRE] The following was proposed by David Hancock and I saw=20 > no disagreement: > - The mechanism SHOULD scale to support several thousand=20 > IP-PBXs on a single service provider network. >=20 > - The mechanism SHOULD require relatively modest changes to a=20 > substantial population of existing SSP and PBX=20 > implementations, in order to encourage a fast market adoption=20 > of the standardized mechanism. >=20 > [JRE] The following proposal from Keith was discussed, but=20 > with no conclusion (or was Adam's objection not so much to=20 > the proposal but to Keith's subsequent assertion that it=20 > means no change to the Request-URI on an inbound request?): >=20 > - The mechanism SHOULD allow handling of inbound requests and=20 > outbound requests between SSP and PBX to be as common as=20 > possible as with a normal peering arrangement (RFC 3263=20 > based), as far as the PBX is concerned. >=20 >=20 > John >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Mon Jan 25 08:28:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AEE43A67C1 for ; Mon, 25 Jan 2010 08:28:23 -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=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWZKgO9ZgXgM for ; Mon, 25 Jan 2010 08:28:22 -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 121723A6857 for ; Mon, 25 Jan 2010 08:28:21 -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-658174 for martini@ietf.org; Mon, 25 Jan 2010 17:13:27 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 73A3423F0292 for ; Mon, 25 Jan 2010 17:13:27 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 25 Jan 2010 17:13:27 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Mon, 25 Jan 2010 17:13:26 +0100 Thread-Topic: Evaluation of issues solved by martini-up Thread-Index: Acqd0NBRyaRdVLodTfK2K2A5lp7rBg== 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: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:28:23 -0000 Section 9 of draft-roach-martini-up-00 describes the issues (from mixing-pr= oblems) solved by the proposal. Most of these issues can be solved using a = REGISTER-based approach - see my interleaved remarks. "No Explicit Indicator: The mechanism in this document cannot be confused with the normal registration mechanism defined in RFC 3261, as it does not attempt to overload REGISTER to convey bulk dynamic routing information." [JRE] That is why we propose some explicit indication. "Undefined Behavior on PAU Mismatch: By shifting the task of specifying the AORs being registered from the server to the client, there is no opportunity for mismatch. Policy errors may arise when the client attempts to register for AORs other than those it is authorized to register; however, procedures for detecting and addressing these conditions are provided." [JRE] Ensuring a matching set of AORs is a provisioning issue, and does not= need to be part of the dynamic update mechanism. "REGISTER Response Growth: By shifting the task of specifying the AORs being registered from the server to the client, normal response size is maintained. Circumstances under which a UDP response is required, but size precludes sending a response, are precluded." [JRE] I would agree with removing it from the response, but I doubt the nee= d to include it in the request - see previous point. "Illegal Wildcarding Syntax: By defining a wildcarding syntax outside the strictures of SIP, the issue of valid SIP syntax is sidestepped." [JRE] Can be avoided - see previous two points. "Loss of Target Info: Because the binding from AOR to Contact URI is under complete control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Target information is preserved." [JRE] Indeed, and any REGISTER-based proposal would likewise need to preser= ve the information. "Request-URI vs. Loose-Route Mismatches: As before: because the binding from AOR to Contact URI is under complete control of the requestor, and because the model of proxy/registrar routing defined in RFC 3261 is maintained, the system exhibits the same properties as it would if each user were registered individually. Loose routing and Request-URI handling are kept consistent with proxy/registrar handling described in RFC 3261, so no mismatches can arise." [JRE] I am not sure that we necessarily need all properties to the same as = if each user were registered separately, but it is certainly important that= an inbound request correctly identify the target AOR. So I don't see this = as being different from the previous point. "Authorization Policy Mismatches: Because the binding from AOR to Contact URI is under control of the publisher, it can ensure that the Contact URI associated with an AOR matches the Contact URIs it uses for outgoing calls. This eliminates the authorization policy mismatches described." [JRE] Any proposal that allows one contact URI per AOR would get around thi= s problem. "P-Asserted-Identity Mismatches: Because the information published by this mechanism inherently mimics individual registration for each of the associated AORs, the expectation that each of these AORs can be used as a P-Asserted-Identity is preserved, avoiding any implementation confusion regarding valid values for this field." [JRE] Ditto. "Trust Domain Mismatches for Privacy/Identity: The MARTINI working group appears to be reaching rough consensus that this issue is out of scope and out of charter for solutions it is responsible for considering. It is not analyzed with respect to the proposed solution." John From bruno.chatras@orange-ftgroup.com Mon Jan 25 08:35:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C58E3A6848 for ; Mon, 25 Jan 2010 08:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 Uw0PDtd4oWzY for ; Mon, 25 Jan 2010 08:35:37 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 5A5013A67E7 for ; Mon, 25 Jan 2010 08:35:37 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 9A001324414; Mon, 25 Jan 2010 17:35:43 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8190635C061; Mon, 25 Jan 2010 17:35:43 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 17:35:42 +0100 Message-ID: <18230_1264437343_4B5DC85F_18230_4907_1_9ECCF01B52E7AB408A7EB853526421410101AAFF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Evaluation of issues solved by martini-up Thread-Index: Acqd0NBRyaRdVLodTfK2K2A5lp7rBgACzmSg References: From: To: , X-OriginalArrivalTime: 25 Jan 2010 16:35:44.0143 (UTC) FILETIME=[70A0C1F0:01CA9DDC] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.25.160622 Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:35:38 -0000 > "REGISTER Response Growth: By shifting the task of specifying the > AORs being registered from the server to the client, normal > response size is maintained. Circumstances under which a UDP > response is required, but size precludes sending a response, are > precluded." > [JRE] I would agree with removing it from the response, but I=20 > doubt the need to include it in the request - see previous point. >=20 You may remove it from the interface between the SSP's edge proxy and the PBX but not between the registrar and the SSP's edge proxy. Otherwise you rule out the "untrusted model" as the edge proxy will be unable to assert identities in this case. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From spencer@wonderhamster.org Mon Jan 25 08:42:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5593A6889 for ; Mon, 25 Jan 2010 08:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_20=-0.74, STOX_REPLY_TYPE=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 FzsSX+PHf5rm for ; Mon, 25 Jan 2010 08:42:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 01A993A67E7 for ; Mon, 25 Jan 2010 08:42:33 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MguSG-1NDOtH0Afw-00MTnx; Mon, 25 Jan 2010 11:42:37 -0500 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , References: Date: Mon, 25 Jan 2010 10:42:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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+CXxQ11MrOoMX975Sf/GIv8lW6y1BemXjwApm nTg/VAeepaGOos9Tw7A6gYibhMkCS4bpo8FWYu/+rsk64W6g4Y whqbKViLa0piV6OlDldJJsX7AySFjiAstMdiQSReoc= Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:42:34 -0000 Hi, John, (As co-chair) Thanks for continuing to herd this along the path. (as individual) A couple of questions inline... > - The mechanism MUST allow the PBX to be responsible for its AORs and to > handle requests to those AORs according to its rules. Are we crystal clear on what "responsible for its AORs" means? I am remembering conversations that centered around where DNS records pointed, for instance. > - The mechanism MUST work in the presence of intermediate "proxies" on the > SSP side of the interface (between the PBX and the SSP's domain proxy), > where those intermediate "proxies" need to be on the path of inbound > requests to the PBX. > [JRE] There was a comment from Bruno to extend this to proxies on the PBX > side, but I didn't see any consensus to accept this. I am somewhat concerned about "proxies" in quotes. Do people think this requirement is talking about normal SIP-trapezoid proxies, or does it include other types of middleboxes like B2BUAs? I don't think we've been completely consistent about this. > - The mechanism SHOULD scale to PBXs of several thousand AORs. I was hoping that someone else would ask about this one, but no one else has. Does anyone on this list actually NEED mass registration for several thousand AORs? We've been coy about defining values for "small" and "medium", but I've been in a lot of conversations that talked about "small" and "medium", and many of these conversations also included sentences like "of course, large PBXes would do RFC 3263". I apologize if I'm connecting the wrong dots, but when I joined Nortel in 1981, the largest PBXes they made topped out at 5000 lines. I wouldn't think of 5000 AORs as a small or medium PBX. If this one stays, I'm going to be paying a lot more intention to state management, atomicity, etc. Rebooting a small PBX for a beauty shop is a lot more attractive than rebooting a PBX for 5000 AoRs... > [JRE] The following was proposed by David Hancock and I saw no > disagreement: > - The mechanism SHOULD scale to support several thousand IP-PBXs on a > single service provider network. FWIW, I agree with this addition. Spencer (speaking as individual) From john.elwell@siemens-enterprise.com Mon Jan 25 08:58:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6E83A68E1 for ; Mon, 25 Jan 2010 08:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQYhqmsrpID7 for ; Mon, 25 Jan 2010 08:58:22 -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 4D3B03A6884 for ; Mon, 25 Jan 2010 08:58:21 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-658177; Mon, 25 Jan 2010 17:13:27 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 7BD141EB82AB; Mon, 25 Jan 2010 17:13:27 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 25 Jan 2010 17:13:27 +0100 From: "Elwell, John" To: Dean Willis Date: Mon, 25 Jan 2010 17:13:27 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqbNAesUwc7SmzqQ7OMgbrfx9AcdQCoCTjw Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> Keywords: MARTINI In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:58:23 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 22 January 2010 07:25 > To: Elwell, John > Cc: Spencer Dawkins; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 >=20 > On Jan 21, 2010, at 1:43 AM, Elwell, John wrote: > >> > > [JRE] But the problems have been solved for REGISTER using=20 > Outbound, =20 > > Service-Route and Path, so it is a simple matter to reuse those. >=20 > Not really. Adam has effectively pointed out several of the=20 > the rather =20 > large number of issues related to trying to extend the REGISTER =20 > metaphor to cover advertisement of routes for domains and=20 > phone number =20 > ranges. Although it looks good at first glance, once you really dig =20 > into what it means to "register a contact for an AOR" versus =20 > "registering a route for a domain", things start to get messy. =20 > Consider for example the debate we're currently having about whether =20 > the SSP does "contact routing" and replaces the r-URI with a =20 > registered contact, or does "domain routing" and just pushes the =20 > registered route onto the route stack (really, it MUST do the=20 > latter, =20 > but REGISTER implies the former, which makes it something of=20 > a hack). =20 > Seriously, go back and look at Adam's arguments very carefully. He =20 > might wear excessively colorful trousers from time to time, but I =20 > think most of his arguments are spot-on. Please everybody: go read =20 > draft-roach-martini-up-00 and pay very careful attention to Section 9. [JRE] I just read it again, and to be honest most of what it claims could a= lso apply to a well-chosen REGISTER-based mechanism. I will answer specific= points in a separate thread. >=20 > You claim that the use of REGISTER is justified because the trifecta =20 > of Outbound, Service-Route, and Path solves the multi-hop route =20 > advertisement problem. >=20 > Let's consider Outbound, for example. Outbound works for a single =20 > contact of an AOR because it allows binding the credentials of that =20 > single AOR to the persistent connection established to the contact. =20 > Once the "contact" represents a large number of AORs, the security =20 > assumptions around Outbound are completely broken. [JRE] I don't think so - the PBX registers on behalf of a bunch of AORs, an= d we get similar security properties between the PBX and the SP for that bu= nch of AORs to what we would get if we were registering a single AOR. > This, by the way, =20 > is also the "connection reuse" problem. We really need to extend our =20 > AAA model to consider domains and phone-number ranges. Further, =20 > Outbound really provides for connection use at only a single relay =20 > (the "outbound proxy"), and a general solution needs to allow =20 > persistent multi-hop routes (multiple "outbound proxies" in=20 > sequence). =20 [JRE] I would contend that if outbound is broken for MARTINI, it is also br= oken for a normal user registration where there are multiple entities on th= e path. Isn't that what IMS has in the case of roaming users? John > I might, for example, be behind a NAT router at my house,=20 > which is in =20 > itself VPNed to a concentrator at my office, which is also=20 > NATed back =20 > to the Internet, and the "ssp" and "pbx" proxy nodes could be=20 > anywhere =20 > up or down that hierarchy. There might even be multiple layers of =20 > "ssp" proxy involved, and it would be very nice to establish the =20 > required routing dynamically rather than having all that static =20 > configuration. >=20 > As the editor of Service-Route and Path, I can tell you that they're =20 > pretty conclusively broken in the general model. Sure, they work for =20 > the single-point scenarios of IMS that inspired them, but a fully =20 > symmetric general route solution would have been a much cleaner =20 > solution to the problem. >=20 > A maxim to consider: an authenticated single-hop route=20 > towards a user =20 > is NOT the same as an authenticated connection to the user. The same =20 > is true of any multi-hop route that is not authenticated all the way =20 > to the user. Consequently, an authenticated route to a=20 > domain is much =20 > different than a route between an authoritative proxy and a contact =20 > registered to an AOR homed at that proxy. >=20 > Outbound, Route, and Service-Route are all based on the idea that we =20 > have a unique vector through a singular "sticky point" (the outbound =20 > proxy) to a single end user. That, however, is NOT the scenario in =20 > domain/range routing, and the assumptions of the security model =20 > require careful re-examination. >=20 > -- > Dean >=20 > = From spencer@wonderhamster.org Mon Jan 25 09:02:49 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3EBA28C0E2 for ; Mon, 25 Jan 2010 09:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, STOX_REPLY_TYPE=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 BFK4gpaVCSuv for ; Mon, 25 Jan 2010 09:02:49 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 07A7C28C0E5 for ; Mon, 25 Jan 2010 09:02:49 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MONy9-1NThAe0JW9-005yO2; Mon, 25 Jan 2010 12:02:55 -0500 Message-ID: <40403A0B0ABC40388E1BCED3C4776EC0@china.huawei.com> From: "Spencer Dawkins" To: "Elwell, John" , References: Date: Mon, 25 Jan 2010 11:02:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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/vCb9VvDud30d+DB0SnaP3gEXSc3mjUD2/gKZ mBD40ZRLvkHHlgJPws+KOtluj52cFF9dUtBpwbXtx9uC/cjADN MKaG7gdyDS2eLmj8l38Ke5gAYE5zOLTMi223r/trrY= Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:02:49 -0000 (as co-chair) To John, Thanks for walking through these points - it's helpful. (as individual) To all, but especially to Adam, I've heard two assertions offlist that I wanted to bring on-list before tomorrow's call, so that people have a chance to check their own products/networks, think, and perform other active verbs, before we talk... Someone pointed out to me that using SBCs to drop traffic that doesn't correspond to an active registration is a fairly widespread practice for providers who support small PBXs today. If this is the case, we would be creating a dependency that this filtering change if we use a solution based on PUBLISH, Dean's proposed RUPDATE, etc. Someone pointed out to me that carriers special-case avalanche restart procedures for REGISTER. Again, this would have to change if we adopt a solution based on PUBLISH, Dean's proposed RUPDATE, etc. Thanks, Spencer From john.elwell@siemens-enterprise.com Mon Jan 25 09:05:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805203A68ED for ; Mon, 25 Jan 2010 09:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 cjD67AAJSy19 for ; Mon, 25 Jan 2010 09:05:03 -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 C9EBD3A67B2 for ; Mon, 25 Jan 2010 09:05:02 -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-659039; Mon, 25 Jan 2010 18:05:09 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 00BBD1EB82AB; Mon, 25 Jan 2010 18:05:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 25 Jan 2010 18:05:08 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "martini@ietf.org" Date: Mon, 25 Jan 2010 18:05:08 +0100 Thread-Topic: [martini] Requirements - rev2 Thread-Index: AcqPtcNTrMvo3HncR6m5uvjHKZ/psQOJF6BgAAF3CCA= Message-ID: References: <20708_1264436515_4B5DC523_20708_51782_1_9ECCF01B52E7AB408A7EB853526421410101AAB8@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20708_1264436515_4B5DC523_20708_51782_1_9ECCF01B52E7AB408A7EB853526421410101AAB8@ftrdmel0.rd.francetelecom.fr> 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: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:05:04 -0000 Bruno, We already have the requirement: "The mechanism MUST provide a means whereb= y the PBX knows which of its AORs an inbound request is targeted at." You seem to suggest this should be further qualified by saying this should = be in the Request-URI, but I am concerned this is more part of the solution= than a requirement. It is also related to the later point (still under discussion): "The mechan= ism SHOULD allow handling of inbound requests and outbound requests between= SSP and PBX to be as common as possible as with a normal peering arrangeme= nt (RFC 3263 based), as far as the PBX is concerned." So I am hesitant to add anything further. Let's see what others say. John > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 25 January 2010 16:22 > To: Elwell, John; martini@ietf.org > Subject: RE: [martini] Requirements - rev2 >=20 > If there is no consensus on adding the requirements about=20 > intermediate proxies at the PBX side could we instead add=20 > something like "The mechanism MUST allow the PBX to uniquely=20 > identify the communication target based solely on the=20 > contents of the Request-URI on inbound requests."? >=20 >=20 >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > > Envoy=E9 : lundi 25 janvier 2010 17:13 > > =C0 : martini@ietf.org > > Objet : [martini] Requirements - rev2 > >=20 > > Although the "Requirement - rev1" thread had a lot of traffic=20 > > over the last couple of weeks, very little of that traffic=20 > > led to consensus on change to the requirements list. So below=20 > > is the requirements list again with my comments inserted=20 > > ("[JRE]") where there has been discussion. > >=20 > > Please continue the feedback so that we can have a meaningful=20 > > discussion on tomorrow's call. > >=20 > >=20 > > - The mechanism MUST allow the PBX to be responsible for its=20 > > AORs and to handle requests to those AORs according to its rules. > >=20 > > - The mechanism MUST allow the PBX to receive requests to its=20 > > AORs that originate off-PBX and arrive via the SSP, so that=20 > > the PBX can handle those requests according to its rules. > >=20 > > - The mechanism MUST provide a means whereby the PBX knows=20 > > which of its AORs an inbound request is targeted at. > >=20 > > - The mechanism MUST provide a means of avoiding problems due=20 > > to one side using the mechanism and the other side not. > >=20 > > - The mechanism MUST observe SIP backwards compatibility principles. > >=20 > > - The mechanism MUST work in the presence of intermediate=20 > > "proxies" on the SSP side of the interface (between the PBX=20 > > and the SSP's domain proxy), where those intermediate=20 > > "proxies" need to be on the path of inbound requests to the PBX. > > [JRE] There was a comment from Bruno to extend this to=20 > > proxies on the PBX side, but I didn't see any consensus to=20 > > accept this. > >=20 > > - The mechanism MUST work when the PBX obtains its IP address=20 > > dynamically. > >=20 > > - The mechanism MUST work without requiring the PBX to=20 > > publish reachability information through the DNS. > >=20 > > Also some desiderata: > > - The mechanism SHOULD allow SSPs to exploit its mechanisms=20 > > for providing SIP service to ordinary subscribers in order to=20 > > provide a SIP trunking service to PBXs. > >=20 > > - The mechanism SHOULD scale to PBXs of several thousand AORs. > >=20 > > [JRE] The following was proposed by David Hancock and I saw=20 > > no disagreement: > > - The mechanism SHOULD scale to support several thousand=20 > > IP-PBXs on a single service provider network. > >=20 > > - The mechanism SHOULD require relatively modest changes to a=20 > > substantial population of existing SSP and PBX=20 > > implementations, in order to encourage a fast market adoption=20 > > of the standardized mechanism. > >=20 > > [JRE] The following proposal from Keith was discussed, but=20 > > with no conclusion (or was Adam's objection not so much to=20 > > the proposal but to Keith's subsequent assertion that it=20 > > means no change to the Request-URI on an inbound request?): > >=20 > > - The mechanism SHOULD allow handling of inbound requests and=20 > > outbound requests between SSP and PBX to be as common as=20 > > possible as with a normal peering arrangement (RFC 3263=20 > > based), as far as the PBX is concerned. > >=20 > >=20 > > John > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > = From john.elwell@siemens-enterprise.com Mon Jan 25 09:18:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C993A67B2 for ; Mon, 25 Jan 2010 09:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 sLXGkHc6hNSN for ; Mon, 25 Jan 2010 09:18:50 -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 C4F7A3A6407 for ; Mon, 25 Jan 2010 09:18:49 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-659407; Mon, 25 Jan 2010 18:18:55 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id F1BE41EB82AB; Mon, 25 Jan 2010 18:18:54 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 25 Jan 2010 18:18:54 +0100 From: "Elwell, John" To: Adam Roach , Paul Kyzivat Date: Mon, 25 Jan 2010 18:18:53 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: Acqd0CBe6DVNJXvPRJCrtQld7NaBYAAEi7wg Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> <4B5DB3AE.40107@nostrum.com> In-Reply-To: <4B5DB3AE.40107@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" , Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:18:51 -0000 For the two domain case, using a REGISTER-based approach, I would expect th= e PBX to behave as two PBXs and register twice.=20 John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 25 January 2010 15:07 > To: Paul Kyzivat > Cc: Elwell, John; Dean Willis; Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/25/10 8:40 AM, Paul Kyzivat wrote:=20 >=20 > inline...=20 > =09 > Elwell, John wrote:=20 > =09 >=20 >=20 > -----Original Message-----=20 > From: Adam Roach=20 > [mailto:adam@nostrum.com] Sent: 22 January 2010 17:16=20 > =09 >=20 >=20 > This is great! Now we're using REGISTER=20 > to put an AOR to Contact mapping in place (like it always=20 > has) instead of using it to install rules to override normal=20 > RFC3263 handling. Best of all, we're not saying "ignore DNS=20 > and use this alternate mechanism for turning names into=20 > addresses" like we have to with the "domain routing" approach.=20 > =09 >=20 > [JRE] This would seem reasonable. The point is,=20 > if the PBX registers as its contact address pbx123@10.15.2.4,=20 > then inbound INVITE requests would not contain that same=20 > value in the Request-URI, but would contain something like=20 > dsmith@10.15.2.4. The identity of the target is retained. So=20 > I think we are in agreement.=20 > =09 >=20 >=20 > This could probably be made to work.=20 > =09 > But it requires new conventions about the form of contact URIs,=20 > conventions we have never had before.=20 > =09 > The rule has always been that the registering device=20 > can use whatever contact URI it wishes, as long as it routes=20 > to itself, and in particular it can use the user-info portion=20 > of that URI to encode arbitrary information that may be=20 > helpful to itself.=20 > =09 > If an special convention is required for this new=20 > mechanism, then we need to be very explicit about it.=20 > =09 >=20 >=20 > I'd like to be explicit about it at a protocol level. >=20 > I'll reiterate that the AOR to Contact mapping model I=20 > propose in draft-roach-martini-up is *not* specific to the=20 > use of PUBLISH. Using a similar mechanism in REGISTER --=20 > whether in the header or in the body -- would achieve the=20 > same goals. More importantly, it would address Dean's concern: >=20 >=20 >=20 > What happens when the PBX supports two domains, and=20 > there might be user-name overlaps between the domains? If=20 > both dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are=20 > contact-routed by the SSP into dwillis@10.1.2.3, we have=20 > something of a mess. >=20 >=20 > Because, in this case, the registration could look something=20 > like this (using the syntax from martini-up): >=20 >=20 >=20 > 1 full > /sip:(.*)@eng.pan-am.com/sip:\1-eng@10.2.14.7/ > /sip:(.*)@mktg.pan-am.com/sip:\1-mktg@10.2.14.7/ > =09 >=20 >=20 > That's very explicit. It's not even a convention; it's a protocol. >=20 > /a >=20 >=20 > = From john.elwell@siemens-enterprise.com Mon Jan 25 09:35:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1063A6407 for ; Mon, 25 Jan 2010 09:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 CAfmiTHpfrrh for ; Mon, 25 Jan 2010 09:35: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 DE4C03A6804 for ; Mon, 25 Jan 2010 09:35: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-659396; Mon, 25 Jan 2010 18:35:22 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id EE46023F0292; Mon, 25 Jan 2010 18:35:21 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 25 Jan 2010 18:35:21 +0100 From: "Elwell, John" To: Spencer Dawkins , "martini@ietf.org" Date: Mon, 25 Jan 2010 18:35:20 +0100 Thread-Topic: [martini] Requirements - rev2 Thread-Index: Acqd3WhjfgQ0hiz0TlO9KWMBwvqMaAABrUPQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:35:17 -0000 Spencer, My feedback below.=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Sent: 25 January 2010 16:42 > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev2 >=20 > Hi, John, >=20 > (As co-chair) Thanks for continuing to herd this along the path. >=20 > (as individual) A couple of questions inline... >=20 >=20 > > - The mechanism MUST allow the PBX to be responsible for=20 > its AORs and to=20 > > handle requests to those AORs according to its rules. >=20 > Are we crystal clear on what "responsible for its AORs" means? I am=20 > remembering conversations that centered around where DNS=20 > records pointed,=20 > for instance. [JRE] Yes, I agree we need something more concrete. Any text proposals from= anyone? >=20 > > - The mechanism MUST work in the presence of intermediate=20 > "proxies" on the=20 > > SSP side of the interface (between the PBX and the SSP's=20 > domain proxy),=20 > > where those intermediate "proxies" need to be on the path=20 > of inbound=20 > > requests to the PBX. > > [JRE] There was a comment from Bruno to extend this to=20 > proxies on the PBX=20 > > side, but I didn't see any consensus to accept this. >=20 > I am somewhat concerned about "proxies" in quotes. Do people=20 > think this=20 > requirement is talking about normal SIP-trapezoid proxies, or does it=20 > include other types of middleboxes like B2BUAs? I don't think=20 > we've been=20 > completely consistent about this. [JRE] Yes, it certainly needs to work with B2BUAs in their various forms. P= erhaps just changing it to "SIP entities"? >=20 > > - The mechanism SHOULD scale to PBXs of several thousand AORs. >=20 > I was hoping that someone else would ask about this one, but=20 > no one else=20 > has. >=20 > Does anyone on this list actually NEED mass registration for several=20 > thousand AORs? >=20 > We've been coy about defining values for "small" and=20 > "medium", but I've been=20 > in a lot of conversations that talked about "small" and=20 > "medium", and many=20 > of these conversations also included sentences like "of=20 > course, large PBXes=20 > would do RFC 3263". >=20 > I apologize if I'm connecting the wrong dots, but when I=20 > joined Nortel in=20 > 1981, the largest PBXes they made topped out at 5000 lines. I=20 > wouldn't think=20 > of 5000 AORs as a small or medium PBX. [JRE] I tend to agree, that scalability to perhaps a few 100 AORs should be= sufficient, but I seem to remember suggestions that it should be scalable = to even bigger deployments. Any other views? John >=20 > If this one stays, I'm going to be paying a lot more=20 > intention to state=20 > management, atomicity, etc. Rebooting a small PBX for a=20 > beauty shop is a lot=20 > more attractive than rebooting a PBX for 5000 AoRs... >=20 > > [JRE] The following was proposed by David Hancock and I saw no=20 > > disagreement: > > - The mechanism SHOULD scale to support several thousand=20 > IP-PBXs on a=20 > > single service provider network. >=20 > FWIW, I agree with this addition. >=20 > Spencer (speaking as individual)=20 >=20 > = From pkyzivat@cisco.com Mon Jan 25 09:45:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B519F3A68A5 for ; Mon, 25 Jan 2010 09:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIcVaHPXfmda for ; Mon, 25 Jan 2010 09:45:51 -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 D72083A67F7 for ; Mon, 25 Jan 2010 09:45:51 -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: ApoEALBnXUutJV2Z/2dsb2JhbADFPZVzhDsE X-IronPort-AV: E=Sophos;i="4.49,340,1262563200"; d="scan'208";a="472510156" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 25 Jan 2010 17:45:58 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0PHjwKX013264; Mon, 25 Jan 2010 17:45:58 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 11:45:58 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 11:45:57 -0600 Message-ID: <4B5DD8D3.5050705@cisco.com> Date: Mon, 25 Jan 2010 12:45:55 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 17:45:58.0037 (UTC) FILETIME=[404DF450:01CA9DE6] Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:45:52 -0000 Elwell, John wrote: >> I apologize if I'm connecting the wrong dots, but when I >> joined Nortel in >> 1981, the largest PBXes they made topped out at 5000 lines. I >> wouldn't think >> of 5000 AORs as a small or medium PBX. > [JRE] I tend to agree, that scalability to perhaps a few 100 AORs should be sufficient, but I seem to remember suggestions that it should be scalable to even bigger deployments. Any other views? Is there an implicit assumption here that however many of these there are, it must be possible to encode a list of them in a message that doesn't exceed PDU size? The wildcard proposals certainly attempt to compress the encoding, but in general those only work if the majority of the AORs have some textual commonalities that can be exploited. But while that is the norm, there are no guarantees that a pbx might not have 100 distinct phone numbers that have no patterned relationship that can be exploited via regular expressions to encode the full set concisely. Thanks, Paul From bernard_aboba@hotmail.com Mon Jan 25 10:08:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85EA28C0E8 for ; Mon, 25 Jan 2010 10:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, 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 1iHeRy7o+k67 for ; Mon, 25 Jan 2010 10:08:17 -0800 (PST) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by core3.amsl.com (Postfix) with ESMTP id 13A4E3A688D for ; Mon, 25 Jan 2010 10:08:17 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.72]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 10:08:23 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , References: In-Reply-To: Date: Mon, 25 Jan 2010 10:09:36 -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: Acqd3WHxe25SrQdeTlKLPFUZUk5hYgAC8ykQ Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2010 18:08:23.0830 (UTC) FILETIME=[6275AB60:01CA9DE9] Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:08:17 -0000 Spencer said: "> - The mechanism SHOULD scale to PBXs of several thousand AORs. I was hoping that someone else would ask about this one, but no one else has. Does anyone on this list actually NEED mass registration for several thousand AORs?" [BA] Question: Are there existing installations that use "implicit registration" at this kind of scale? Or alternatively, are there specific customers that have made this request? From adam@nostrum.com Mon Jan 25 10:31:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D1628C0EA for ; Mon, 25 Jan 2010 10:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=0.290, 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 tQhK9W90Zi12 for ; Mon, 25 Jan 2010 10:31:32 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C776A28C0CE for ; Mon, 25 Jan 2010 10:31:31 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PIVa4M021456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 12:31:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DE388.3080604@nostrum.com> Date: Mon, 25 Jan 2010 12:31:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:31:33 -0000 On 1/25/10 10:13 AM, Elwell, John wrote: > "Authorization Policy Mismatches: Because the binding from AOR to > Contact URI is under control of the publisher, it can ensure that > the Contact URI associated with an AOR matches the Contact URIs it > uses for outgoing calls. This eliminates the authorization policy > mismatches described." > > [JRE] Any proposal that allows one contact URI per AOR would get around this problem. > Yes, it would. And, as you point out, it solves other problems as well. In fact, this one property itself makes the majority of the problems in the mixing-problems draft pretty much disappear. While I still think we have problems with using REGISTER for multiple users (see Dean's message regarding the security properties of doing so), simply taking the approach in martini-shaken and adding the regex approach from martini-up goes a long way towards making the entire set of issues far more tractable. /a From adam@nostrum.com Mon Jan 25 10:42:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525F828C0FE for ; Mon, 25 Jan 2010 10:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.193, 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 WeHPY6uuYbZj for ; Mon, 25 Jan 2010 10:42:39 -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 D464728C0FC for ; Mon, 25 Jan 2010 10:42:37 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PIgdnG022265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 12:42:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DE61F.70302@nostrum.com> Date: Mon, 25 Jan 2010 12:42:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 18:42:40 -0000 On 1/25/10 10:13 AM, Elwell, John wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> >> Seriously, go back and look at Adam's arguments very carefully. He >> might wear excessively colorful trousers from time to time, but I >> think most of his arguments are spot-on. Please everybody: go read >> draft-roach-martini-up-00 and pay very careful attention to Section 9. >> > [JRE] I just read it again, and to be honest most of what it claims could also apply to a well-chosen REGISTER-based mechanism. > I agree, with emphasis on the terms "most" and "well-chosen." I would not be entirely opposed to exploring what would constitute "well-chosen," and then figuring out how to solve the problems that fall outside the envelope covered by your term "most." Based on your analysis post, your definition of "well-chosen" inherently includes some programmatic mapping from AORs to Contacts ("one contact URI per AOR," implying contact routing, not domain routing). I think that's a good place to start working from. Don't get hung up on martini-up's proposal to use PUBLISH. While it does solve a very real class of problems, that one relatively minor aspect of the draft is not the most mechanism it proposes. The majority of the problems it solves involve the explicit signaling of AORs in the request, the definition of a mechanism that enables "one contact URI per AOR," and the congruence with previous uses of REGISTER by employing "contact routing" instead of "domain routing." /a From richard@shockey.us Mon Jan 25 11:09:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B6928C0EA for ; Mon, 25 Jan 2010 11:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 0rNaKx+yTfae for ; Mon, 25 Jan 2010 11:09:47 -0800 (PST) Received: from outbound-mail-111.bluehost.com (outbound-mail-111.bluehost.com [69.89.18.7]) by core3.amsl.com (Postfix) with SMTP id E180D3A683C for ; Mon, 25 Jan 2010 11:09:46 -0800 (PST) Received: (qmail 5340 invoked by uid 0); 25 Jan 2010 19:09:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 25 Jan 2010 19:09:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=IDKOt1W7vKgBCjrSZ+b9fzaP+0WfWBGoo/OTz2N5EVXDpnH4SQpx7CVXq4NOPZKMfLpqobduRwRdQe8g+HuyoSzWm1K6Km4B4ZoytNttQm+QmOVt9oiOwiKHH4gv9PgM; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NZUJr-0006SD-PG for martini@ietf.org; Mon, 25 Jan 2010 12:09:51 -0700 Message-ID: <4B5DEC7E.4000808@shockey.us> Date: Mon, 25 Jan 2010 14:09:50 -0500 From: Richard Shockey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: <4B5DE388.3080604@nostrum.com> In-Reply-To: <4B5DE388.3080604@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:09:48 -0000 On 1/25/2010 1:31 PM, Adam Roach wrote: > On 1/25/10 10:13 AM, Elwell, John wrote: >> "Authorization Policy Mismatches: Because the binding from AOR to >> Contact URI is under control of the publisher, it can ensure that >> the Contact URI associated with an AOR matches the Contact >> URIs it >> uses for outgoing calls. This eliminates the authorization >> policy >> mismatches described." >> >> [JRE] Any proposal that allows one contact URI per AOR would get >> around this problem. > > Yes, it would. And, as you point out, it solves other problems as > well. In fact, this one property itself makes the majority of the > problems in the mixing-problems draft pretty much disappear. > > While I still think we have problems with using REGISTER for multiple > users (see Dean's message regarding the security properties of doing > so), simply taking the approach in martini-shaken and adding the regex > approach from martini-up goes a long way towards making the entire set > of issues far more tractable. But would it deploy? This IMHO is the larger issue with the regex concept in PUBLISH ( though it has considerable merit) is that it will probably break other provisioning systems in existing SSP networks. Everyone ...myself included would have supported the PUBLISH method if it had been proposed 6 years ago..but we didnt know what was going to actually happen as smaller PBX systems connected to SSP's. The Option-Tag in shaken has the simple elegance of actually making the semantics of the implicit REGISGTER message actually match what is in the field now and reduce well known interoperability problems that have arisen from a lack of a "explicit" tag informing the SSP proxy what this message is actually trying do. I do not accept the argument that Ben and others made that if you have to open up the code base of SSP proxy's to accept the Option Tag you might as well just do PUBLISH. I'm convinced that it is not that simple at all especially if the requirement is new code to implement the regex. But I will leave it to representatives of SSP's to comment on that directly, because in the final analysis its the SSP that will have to live with the MARTINI solution. I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion. -- Richard Shockey Shockey Consulting Chairman of Board SIP Forum Voice +1 703 593 2683 Skype etc : rshockey101 From adam@nostrum.com Mon Jan 25 11:14:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0359628C0EC for ; Mon, 25 Jan 2010 11:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145, 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 4z5pb5gjE32x for ; Mon, 25 Jan 2010 11:14:12 -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 5FD9F3A67F0 for ; Mon, 25 Jan 2010 11:14:12 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PJEB9H024641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:14:12 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DED83.2000407@nostrum.com> Date: Mon, 25 Jan 2010 13:14:11 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:14:14 -0000 On 1/25/10 3:25 AM, Elwell, John wrote: >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> >> ... >> >> Now, if we stick with the "the SSP does not rewrite the URI" >> approach that Keith and John are rather adamant about, the >> only thing we can really do in terms of "these numbers go >> here, those numbers go there" looks something like this: >> > [JRE] Although I may not have made myself clear, what I really am adamant about is preserving the identity of the target user in the Request-URI. So if the domain part is changed, but the user-info part is retained, that would be satisfactory. > ... >> This is great! Now we're using REGISTER to put an AOR to >> Contact mapping in place (like it always has) instead of >> using it to install rules to override normal RFC3263 >> handling. Best of all, we're not saying "ignore DNS and use >> this alternate mechanism for turning names into addresses" >> like we have to with the "domain routing" approach. >> > [JRE] This would seem reasonable. The point is, if the PBX registers as its contact address pbx123@10.15.2.4, then inbound INVITE requests would not contain that same value in the Request-URI, but would contain something like dsmith@10.15.2.4. The identity of the target is retained. So I think we are in agreement. > I think you're right. It would appear that our positions are not as far apart as they originally seemed. /a From spencer@wonderhamster.org Mon Jan 25 11:16:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3946E3A685F for ; Mon, 25 Jan 2010 11:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_05=-1.11, STOX_REPLY_TYPE=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 1lsX68GkDG83 for ; Mon, 25 Jan 2010 11:16:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D6C993A67CC for ; Mon, 25 Jan 2010 11:16:53 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MhBVJ-1NDAMH3ie9-00MCsN; Mon, 25 Jan 2010 14:16:56 -0500 Message-ID: From: "Spencer Dawkins" To: "Bernard Aboba" , References: Date: Mon, 25 Jan 2010 13:16:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX19oDwIFAi4HCqLH80VW/4S9j8sYS9z8ru7DBnI LdhofoUqsQp9f/0u+WezQae7TonduTMP3OjLKd+lD2N0419hTe OXEMGGQ13zj/UYUJEyOmNn+8dZcVz/JRCDOkHLIznQ= Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:16:55 -0000 Bernard is asking a much better-formed version of my question - thanks for clarifying! Spencer > Spencer said: > > "> - The mechanism SHOULD scale to PBXs of several thousand AORs. > > I was hoping that someone else would ask about this one, but no one else > has. > > Does anyone on this list actually NEED mass registration for several > thousand AORs?" > > [BA] Question: Are there existing installations that use "implicit > registration" at this kind of scale? > Or alternatively, are there specific customers that have made this > request? From adam@nostrum.com Mon Jan 25 11:27:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B533A68D7 for ; Mon, 25 Jan 2010 11:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, 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 u6NM7fsCtoTu for ; Mon, 25 Jan 2010 11:27: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 D2B203A68D5 for ; Mon, 25 Jan 2010 11:27:42 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PJRmiX025642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:27:48 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DF0B4.6000301@nostrum.com> Date: Mon, 25 Jan 2010 13:27:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Richard Shockey References: <4B5DE388.3080604@nostrum.com> <4B5DEC7E.4000808@shockey.us> In-Reply-To: <4B5DEC7E.4000808@shockey.us> Content-Type: multipart/alternative; boundary="------------010608060006020206030809" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:27:44 -0000 This is a multi-part message in MIME format. --------------010608060006020206030809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/25/10 1:09 PM, Richard Shockey wrote: > > I still wish folks would understand the underlying business issues > that have driven folks to this point in the discussion. > I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that. I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors. The deployed techniques don't qualify. The approaches simply have fundamental flaws that are too profound to paper over with an option tag. I can appreciate the expedience of addressing foundation problems by caulking the cracks in the walls, but also recognize that you've done nothing to solve the underlying problems when you do so. You're effectively arguing that we need to ratify hodgepodge solutions developed in the field or risk being ignored on this topic. I think we're better off risking being ignored if the only other option is blindly ratifying broken protocol extensions. Being ignored on this topic may yield irrelevance on this one topic; ratifying broken solutions leads to permanent irrelevance on all topics from now on. /a --------------010608060006020206030809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit  On 1/25/10 1:09 PM, Richard Shockey wrote:

I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion.


I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that.

I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors.

The deployed techniques don't qualify. The approaches simply have fundamental flaws that are too profound to paper over with an option tag. I can appreciate the expedience of addressing foundation problems by caulking the cracks in the walls, but also recognize that you've done nothing to solve the underlying problems when you do so.

You're effectively arguing that we need to ratify hodgepodge solutions developed in the field or risk being ignored on this topic. I think we're better off risking being ignored if the only other option is blindly ratifying broken protocol extensions. Being ignored on this topic may yield irrelevance on this one topic; ratifying broken solutions leads to permanent irrelevance on all topics from now on.

/a
--------------010608060006020206030809-- From adam@nostrum.com Mon Jan 25 11:52:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EFFE3A6834 for ; Mon, 25 Jan 2010 11:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.097, 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 aCXre8eqVh13 for ; Mon, 25 Jan 2010 11:52:51 -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 258213A682E for ; Mon, 25 Jan 2010 11:52:50 -0800 (PST) Received: from [172.16.3.81] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PJquUQ027505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 13:52:56 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DF698.7010902@nostrum.com> Date: Mon, 25 Jan 2010 13:52:56 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Richard Shockey References: <4B5DE388.3080604@nostrum.com> <4B5DEC7E.4000808@shockey.us> In-Reply-To: <4B5DEC7E.4000808@shockey.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 19:52:52 -0000 On 01/25/2010 01:09 PM, Richard Shockey wrote: > I do not accept the argument that Ben and others made that if you have > to open up the code base of SSP proxy's to accept the Option Tag you > might as well just do PUBLISH. Don't get hung up on martini-up's proposal to use PUBLISH. While it does solve a very real class of problems, that one relatively minor aspect of the draft is not the most important mechanism it proposes. The majority of the problems it solves involve the explicit signaling of AORs in the request, the definition of a mechanism that enables "one contact URI per AOR," and the congruence with previous uses of REGISTER by employing "contact routing" instead of "domain routing." /a From adam@nostrum.com Mon Jan 25 12:05:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C863B3A68D9 for ; Mon, 25 Jan 2010 12:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, 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 FYqKUa7yy7Sk for ; Mon, 25 Jan 2010 12:05:30 -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 A51623A68D5 for ; Mon, 25 Jan 2010 12:05:29 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PK4sD9028439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 14:04:54 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DF966.1040408@nostrum.com> Date: Mon, 25 Jan 2010 14:04:54 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <4B5DD8D3.5050705@cisco.com> In-Reply-To: <4B5DD8D3.5050705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:05:30 -0000 On 1/25/10 11:45 AM, Paul Kyzivat wrote: > The wildcard proposals certainly attempt to compress the encoding, but > in general those only work if the majority of the AORs have some > textual commonalities that can be exploited. But while that is the > norm, there are no guarantees that a pbx might not have 100 distinct > phone numbers that have no patterned relationship that can be > exploited via regular expressions to encode the full set concisely. Is this really a requirement? It seems a bit of a tortured use case. /a From adam@nostrum.com Mon Jan 25 12:13:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D9D3A68E1 for ; Mon, 25 Jan 2010 12:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.073, 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 YBaAsYqMoR3G for ; Mon, 25 Jan 2010 12:13:45 -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 BFFD33A6834 for ; Mon, 25 Jan 2010 12:13:44 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PKDeZD029120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 14:13:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DFB74.80802@nostrum.com> Date: Mon, 25 Jan 2010 14:13:40 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Spencer Dawkins References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:13:47 -0000 On 1/25/10 9:18 AM, Spencer Dawkins wrote: > How would we know that the user part is an E.164 number, > unambiguously, so that we don't have to reopen the discussion about > interpreting user parts (which doesn't sound like a short conversation)? I sure would be cool if we didn't have to worry about that, wouldn't it? Perhaps we should solve the general case instead of arguing about how to determine when the special case can be applied. /a From adam@nostrum.com Mon Jan 25 12:22:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3937A3A68F6 for ; Mon, 25 Jan 2010 12:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 7Wy6nuJaaeHV for ; Mon, 25 Jan 2010 12:22:51 -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 313733A68C0 for ; Mon, 25 Jan 2010 12:22:50 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PKMpI1029935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 14:22:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5DFD9A.8070209@nostrum.com> Date: Mon, 25 Jan 2010 14:22:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:22:52 -0000 On 1/25/10 10:13 AM, Elwell, John wrote: > [JRE] The following proposal from Keith was discussed, but with no conclusion (or was Adam's objection not so much to the proposal but to Keith's subsequent assertion that it means no change to the Request-URI on an inbound request?): > > - The mechanism SHOULD allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as with a normal peering arrangement (RFC 3263 based), as far as the PBX is concerned. > To be clear -- I object to the requirement as stated. If we're using REGISTER (or PUBLISH with the 'reg' event package), that means we're setting up AOR => Contact bindings. Inherently, that means contact routing, not the normal inter-domain RFC 3263-based routing. On top of that, anything along these lines starts running into the DNS alt-root problems that have been pointed out repeatedly by myself and others. Anything that says "we're using RFC 3263 techniques, except without the DNS servers" is fraught with peril. /a From pkyzivat@cisco.com Mon Jan 25 12:26:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB4B3A691D for ; Mon, 25 Jan 2010 12:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsX+saX4Eu-Q for ; Mon, 25 Jan 2010 12:26:53 -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 1754F3A6901 for ; Mon, 25 Jan 2010 12:26:53 -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: ApoEANuNXUtAZnwN/2dsb2JhbADEbJYthDkE X-IronPort-AV: E=Sophos;i="4.49,341,1262563200"; d="scan'208";a="81935841" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2010 20:26:59 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0PKQxkF004359; Mon, 25 Jan 2010 20:26:59 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 14:26:59 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 14:26:58 -0600 Message-ID: <4B5DFE8B.1060602@cisco.com> Date: Mon, 25 Jan 2010 15:26:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B5DD8D3.5050705@cisco.com> <4B5DF966.1040408@nostrum.com> In-Reply-To: <4B5DF966.1040408@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 20:26:58.0633 (UTC) FILETIME=[BE77EB90:01CA9DFC] Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:26:54 -0000 Adam Roach wrote: > On 1/25/10 11:45 AM, Paul Kyzivat wrote: >> The wildcard proposals certainly attempt to compress the encoding, but >> in general those only work if the majority of the AORs have some >> textual commonalities that can be exploited. But while that is the >> norm, there are no guarantees that a pbx might not have 100 distinct >> phone numbers that have no patterned relationship that can be >> exploited via regular expressions to encode the full set concisely. > > Is this really a requirement? It seems a bit of a tortured use case. I don't know what sort of tortured cases exist out there in the wild. I'm not arguing for anything specific. I'm just trying to understand the requirements proposed. If its "support up to N distinct AORs and/or AOR-ranges" where an AOR-range is suitably defined, then we can discuss what a suitable value of N might be, and it may be small. But if its "support up to N distinct AORs" with no restriction on what they might be then I think we will find a requirement for a larger value of N. Thanks, Paul From spencer@wonderhamster.org Mon Jan 25 12:35:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2103A68F0 for ; Mon, 25 Jan 2010 12:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.680, 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 BoqYpziJ1Gp2 for ; Mon, 25 Jan 2010 12:35:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 41C023A68A0 for ; Mon, 25 Jan 2010 12:35:46 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MGzr0-1NdPeX2mxu-00DnMw; Mon, 25 Jan 2010 15:35:18 -0500 Message-ID: From: "Spencer Dawkins" To: "Adam Roach" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> <4B5DFB74.80802@nostrum.com> Date: Mon, 25 Jan 2010 14:35:06 -0600 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: V01U2FsdGVkX18XSkQYAPxoSdRYW1+UOJY4CKrn+8N7TstJl92 pA6vSmuGM45A4A3heitbS5IgbLjj8kPrkrtAl9jzOikAi17rs3 fK0+/gOmtUt/AYXdYxqQHo6FAPnUqRLUXylGOzPLvA= Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:35:47 -0000 Hi, Adam, >> How would we know that the user part is an E.164 number, unambiguously, >> so that we don't have to reopen the discussion about interpreting user >> parts (which doesn't sound like a short conversation)? > > I sure would be cool if we didn't have to worry about that, wouldn't it? > Perhaps we should solve the general case instead of arguing about how to > determine when the special case can be applied. Hi, Adam, My understanding here is that we are trying to figure out how the service provider would automagically retarget +12145551212@sp.com (which is directed to the service provider) to +12145551212@pbx.com (which is directed to the PBX), where +12145551212 is an E.164 number that we can know is an E.164 number, and not some SIP administrator's idea of a cruel joke played on an unpleasant co-worker/customer). If I got this wrong, please disabuse me. The limited approach, if we could make it work, would take advantage of the global uniqueness of +12145551212 as an E.164 number, so that the service provider would know it could safely retarget to +12145551212@pbx.com. If we can't take advantage of the global uniqueness of +12145551212, then there's no difference between retargeting +12145551212@sp.com and retargeting spencer@sp.com, so we have to solve the general case to do anything. Am I understanding your point of view correctly? Assuming so - I know that "if wishes were horses, then beggars would ride". I have observed that sometimes, people do ride horses. I'm trying to figure out if we could be riding horses, or if we're just wishing for a pony... Thanks, Spencer - who probably should be speaking as co-chair on this, since we're talking about making a decision that significantly affects the work that MARTINI will do, but is trying to speak as an individual and not speak in favor of one approach as chair. If I'm not succeeding, my apologies for that. Bernard, please feel free to chime in if I'm doing it wrong. From jsburton@cablevision.com Mon Jan 25 12:40:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D433A68A4 for ; Mon, 25 Jan 2010 12:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 QAfLVyG-G0bF for ; Mon, 25 Jan 2010 12:40:08 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 7A0D03A67DD for ; Mon, 25 Jan 2010 12:40:07 -0800 (PST) Received: from c3gwiaoutvs.cablevision.com (c3gwiaoutvs.cablevision.com [10.128.36.189]) by cscpsmout01.cablevision.com (Sentrion-MTA-4.0.2/Sentrion-MTA-4.0.2) with ESMTP id o0PKeEYG016697 for ; Mon, 25 Jan 2010 15:40:14 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o0PKeEYG016697 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1264452014; bh=DtdatFpYWgPxFVVEdrXmLNer4WqOAqv9JVKykPf RB64=; h=Message-Id:Date:From:To:Subject:Mime-Version:Content-Type; b=GWcO1s5SBx/jUyn0mOknpnk07QZIHglF2ZB3TCjE+WrM2fvZFGx0djoq9CPu6RKns t83ZYpo/2N0J2kuodxYbgncSP++O9d+CZtrI4k1DOrJD5peFnJKuVP/W2ScTWSwizBR ayU5rzerEe8THpScTXeh4xSWohC1yE9Ro2IKPWg= Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Mon, 25 Jan 2010 15:40:13 -0500 Message-Id: <4B5D9126.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Mon, 25 Jan 2010 15:40:06 -0500 From: "Jack Burton" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartCAE0D2B6.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:40:10 -0000 --=__PartCAE0D2B6.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The mechanism must be scale to support several thousand IP-PBXs on a single service provider network. I know that we will eventually require support for in excess of 10,000 IP-PBX endpoints. If we're going to continue to require fix-up devices in order to support SIP Trunking toward customers, you can see the economic impact that would have. -Jack Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> "Elwell, John" 1/25/2010 08:13 >>> Although the "Requirement - rev1" thread had a lot of traffic over the last couple of weeks, very little of that traffic led to consensus on change to the requirements list. So below is the requirements list again with my comments inserted ("[JRE]") where there has been discussion. Please continue the feedback so that we can have a meaningful discussion on tomorrow's call. - The mechanism MUST allow the PBX to be responsible for its AORs and to handle requests to those AORs according to its rules. - The mechanism MUST allow the PBX to receive requests to its AORs that originate off-PBX and arrive via the SSP, so that the PBX can handle those requests according to its rules. - The mechanism MUST provide a means whereby the PBX knows which of its AORs an inbound request is targeted at. - The mechanism MUST provide a means of avoiding problems due to one side using the mechanism and the other side not. - The mechanism MUST observe SIP backwards compatibility principles. - The mechanism MUST work in the presence of intermediate "proxies" on the SSP side of the interface (between the PBX and the SSP's domain proxy), where those intermediate "proxies" need to be on the path of inbound requests to the PBX. [JRE] There was a comment from Bruno to extend this to proxies on the PBX side, but I didn't see any consensus to accept this. - The mechanism MUST work when the PBX obtains its IP address dynamically. - The mechanism MUST work without requiring the PBX to publish reachability information through the DNS. Also some desiderata: - The mechanism SHOULD allow SSPs to exploit its mechanisms for providing SIP service to ordinary subscribers in order to provide a SIP trunking service to PBXs. - The mechanism SHOULD scale to PBXs of several thousand AORs. [JRE] The following was proposed by David Hancock and I saw no disagreement: - The mechanism SHOULD scale to support several thousand IP-PBXs on a single service provider network. - The mechanism SHOULD require relatively modest changes to a substantial population of existing SSP and PBX implementations, in order to encourage a fast market adoption of the standardized mechanism. [JRE] The following proposal from Keith was discussed, but with no conclusion (or was Adam's objection not so much to the proposal but to Keith's subsequent assertion that it means no change to the Request-URI on an inbound request?): - The mechanism SHOULD allow handling of inbound requests and outbound requests between SSP and PBX to be as common as possible as with a normal peering arrangement (RFC 3263 based), as far as the PBX is concerned. John -------------------------------------------------------- The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. -------------------------------------------------------- --=__PartCAE0D2B6.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML

The mechanism must be scale to su= pport several thousand IP-PBXs on a single service provider network.  = I know that we will eventually require support for in excess of 10,000 IP-P= BX endpoints.

If we're going to continue to req= uire fix-up devices in order to support SIP Trunking toward customers, you = can see the economic impact that would have.

-Jack=

 

Jack Burton
D= ir. Systems Engineering
Cablevision
jsburton@cablevision.com
516-8= 03-9733


>>> "Elwell, John" <john.elw= ell@siemens-enterprise.com> 1/25/2010 08:13 >>>
Although the= "Requirement - rev1" thread had a lot of traffic over the last couple of w= eeks, very little of that traffic led to consensus on change to the require= ments list. So below is the requirements list again with my comments insert= ed ("[JRE]") where there has been discussion.

Please continue the fe= edback so that we can have a meaningful discussion on tomorrow's call.
<= BR>
- The mechanism MUST allow the PBX to be responsible for its AORs an= d to handle requests to those AORs according to its rules.

- The mec= hanism MUST allow the PBX to receive requests to its AORs that originate of= f-PBX and arrive via the SSP, so that the PBX can handle those requests acc= ording to its rules.

- The mechanism MUST provide a means whereby th= e PBX knows which of its AORs an inbound request is targeted at.

- T= he mechanism MUST provide a means of avoiding problems due to one side usin= g the mechanism and the other side not.

- The mechanism MUST observe= SIP backwards compatibility principles.

- The mechanism MUST work i= n the presence of intermediate "proxies" on the SSP side of the interface (= between the PBX and the SSP's domain proxy), where those intermediate "prox= ies" need to be on the path of inbound requests to the PBX.
[JRE] There = was a comment from Bruno to extend this to proxies on the PBX side, but I d= idn't see any consensus to accept this.

- The mechanism MUST work wh= en the PBX obtains its IP address dynamically.

- The mechanism MUST = work without requiring the PBX to publish reachability information through = the DNS.

Also some desiderata:
- The mechanism SHOULD allow SSPs = to exploit its mechanisms for providing SIP service to ordinary subscribers= in order to provide a SIP trunking service to PBXs.

- The mechanism= SHOULD scale to PBXs of several thousand AORs.

[JRE] The following = was proposed by David Hancock and I saw no disagreement:
- The mechanism= SHOULD scale to support several thousand IP-PBXs on a single service provi= der network.

- The mechanism SHOULD require relatively modest change= s to a substantial population of existing SSP and PBX implementations, in o= rder to encourage a fast market adoption of the standardized mechanism.
=
[JRE] The following proposal from Keith was discussed, but with no conc= lusion (or was Adam's objection not so much to the proposal but to Keith's = subsequent assertion that it means no change to the Request-URI on an inbou= nd request?):

- The mechanism SHOULD allow handling of inbound reque= sts and outbound requests between SSP and PBX to be as common as possible a= s with a normal peering arrangement (RFC 3263 based), as far as the PBX is = concerned.


John



--------------------------------------------------------
The information transmitted in this email and any of its attachments is int= ended only for the person or entity to which it is addressed and may contai= n Cablevision proprietary information, which is privileged, confidential, o= r subject to copyright belonging to Cablevision. Any review, retransmission= , dissemination or other use of, or taking of any action in reliance upon, = this information by persons or entities other than the intended recipient i= s prohibited and may be unlawful. If you received this in error, please con= tact the sender immediately and delete and destroy the communication and al= l of the attachments you have received and all copies thereof.
-------------------------------------------------------- --=__PartCAE0D2B6.0__=-- From spencer@wonderhamster.org Mon Jan 25 12:50:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04573A68F1 for ; Mon, 25 Jan 2010 12:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.543, 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 lk6tNio4M36H for ; Mon, 25 Jan 2010 12:50:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id DE2323A68D0 for ; Mon, 25 Jan 2010 12:50:19 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M93Mz-1NfKO715sD-00CPKe; Mon, 25 Jan 2010 15:50:12 -0500 Message-ID: <5F3462E62B5C4117B821F0081CB2C94A@china.huawei.com> From: "Spencer Dawkins" To: "Jack Burton" , References: <4B5D9126.6D98.00CB.0@cablevision.com> Date: Mon, 25 Jan 2010 14:50:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1454_01CA9DCD.AE06FAF0" 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/7wBYmi007S/inDDBsdT3eKplIwA8FV6Tj7BC HUYPCvb+w5ac3mJTQIXR3GmPGqv0NhtDTf9xEtqx1aiaGEIa9q sJdx6QEI+LuiNiFA0uScnKPfMboaPlFM6wFDMSxbDg= Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 20:50:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1454_01CA9DCD.AE06FAF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Jack, Just to make sure that I'm being clear, my earlier posting was about = several thousand AORs on one SIP-PBX. I understand and agree with the = requirment to support several thousand SIP-PBXes for one service = provider. Thanks, Spencer ----- Original Message -----=20 From: Jack Burton=20 To: martini@ietf.org=20 Sent: Monday, January 25, 2010 2:40 PM Subject: Re: [martini] Requirements - rev2 The mechanism must be scale to support several thousand IP-PBXs on a = single service provider network. I know that we will eventually require = support for in excess of 10,000 IP-PBX endpoints. If we're going to continue to require fix-up devices in order to = support SIP Trunking toward customers, you can see the economic impact = that would have. -Jack =20 Jack Burton Dir. Systems Engineering Cablevision jsburton@cablevision.com 516-803-9733 >>> "Elwell, John" 1/25/2010 = 08:13 >>> Although the "Requirement - rev1" thread had a lot of traffic over the = last couple of weeks, very little of that traffic led to consensus on = change to the requirements list. So below is the requirements list again = with my comments inserted ("[JRE]") where there has been discussion. Please continue the feedback so that we can have a meaningful = discussion on tomorrow's call. - The mechanism MUST allow the PBX to be responsible for its AORs and = to handle requests to those AORs according to its rules. - The mechanism MUST allow the PBX to receive requests to its AORs = that originate off-PBX and arrive via the SSP, so that the PBX can = handle those requests according to its rules. - The mechanism MUST provide a means whereby the PBX knows which of = its AORs an inbound request is targeted at. - The mechanism MUST provide a means of avoiding problems due to one = side using the mechanism and the other side not. - The mechanism MUST observe SIP backwards compatibility principles. - The mechanism MUST work in the presence of intermediate "proxies" on = the SSP side of the interface (between the PBX and the SSP's domain = proxy), where those intermediate "proxies" need to be on the path of = inbound requests to the PBX. [JRE] There was a comment from Bruno to extend this to proxies on the = PBX side, but I didn't see any consensus to accept this. - The mechanism MUST work when the PBX obtains its IP address = dynamically. - The mechanism MUST work without requiring the PBX to publish = reachability information through the DNS. Also some desiderata: - The mechanism SHOULD allow SSPs to exploit its mechanisms for = providing SIP service to ordinary subscribers in order to provide a SIP = trunking service to PBXs. - The mechanism SHOULD scale to PBXs of several thousand AORs. [JRE] The following was proposed by David Hancock and I saw no = disagreement: - The mechanism SHOULD scale to support several thousand IP-PBXs on a = single service provider network. - The mechanism SHOULD require relatively modest changes to a = substantial population of existing SSP and PBX implementations, in order = to encourage a fast market adoption of the standardized mechanism. [JRE] The following proposal from Keith was discussed, but with no = conclusion (or was Adam's objection not so much to the proposal but to = Keith's subsequent assertion that it means no change to the Request-URI = on an inbound request?): - The mechanism SHOULD allow handling of inbound requests and outbound = requests between SSP and PBX to be as common as possible as with a = normal peering arrangement (RFC 3263 based), as far as the PBX is = concerned. John --------------------------------------------------------=20 The information transmitted in this email and any of its attachments = is intended only for the person or entity to which it is addressed and = may contain Cablevision proprietary information, which is privileged, = confidential, or subject to copyright belonging to Cablevision. Any = review, retransmission, dissemination or other use of, or taking of any = action in reliance upon, this information by persons or entities other = than the intended recipient is prohibited and may be unlawful. If you = received this in error, please contact the sender immediately and delete = and destroy the communication and all of the attachments you have = received and all copies thereof.=20 -------------------------------------------------------- -------------------------------------------------------------------------= ----- _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini ------=_NextPart_000_1454_01CA9DCD.AE06FAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Jack,
 
Just to make sure that I'm being clear, = my earlier=20 posting was about several thousand AORs on one SIP-PBX. I understand and = agree=20 with the requirment to support several thousand SIP-PBXes for one = service=20 provider.
 
Thanks,
 
Spencer
----- Original Message -----
From:=20 Jack=20 Burton
Sent: Monday, January 25, 2010 = 2:40=20 PM
Subject: Re: [martini] = Requirements -=20 rev2


The mechanism = must be=20 scale to support several thousand IP-PBXs on a single service provider = network.  I know that we will eventually require support for in = excess of=20 10,000 IP-PBX endpoints.

If we're going = to continue=20 to require fix-up devices in order to support SIP Trunking toward = customers,=20 you can see the economic impact that would have.

-Jack

 

Jack=20 Burton
Dir. Systems=20 = Engineering
Cablevision
jsburton@cablevision.com
516-803-9733


>>>=20 "Elwell, John" <john.elwell@siemens-enterprise.com> 1/25/2010 = 08:13=20 >>>
Although the "Requirement - rev1" thread had a lot of = traffic=20 over the last couple of weeks, very little of that traffic led to = consensus on=20 change to the requirements list. So below is the requirements list = again with=20 my comments inserted ("[JRE]") where there has been = discussion.

Please=20 continue the feedback so that we can have a meaningful discussion on=20 tomorrow's call.


- The mechanism MUST allow the PBX to be=20 responsible for its AORs and to handle requests to those AORs = according to its=20 rules.

- The mechanism MUST allow the PBX to receive requests = to its=20 AORs that originate off-PBX and arrive via the SSP, so that the PBX = can handle=20 those requests according to its rules.

- The mechanism MUST = provide a=20 means whereby the PBX knows which of its AORs an inbound request is = targeted=20 at.

- The mechanism MUST provide a means of avoiding problems = due to=20 one side using the mechanism and the other side not.

- The = mechanism=20 MUST observe SIP backwards compatibility principles.

- The = mechanism=20 MUST work in the presence of intermediate "proxies" on the SSP side of = the=20 interface (between the PBX and the SSP's domain proxy), where those=20 intermediate "proxies" need to be on the path of inbound requests to = the=20 PBX.
[JRE] There was a comment from Bruno to extend this to proxies = on the=20 PBX side, but I didn't see any consensus to accept this.

- The=20 mechanism MUST work when the PBX obtains its IP address = dynamically.

-=20 The mechanism MUST work without requiring the PBX to publish = reachability=20 information through the DNS.

Also some desiderata:
- The = mechanism=20 SHOULD allow SSPs to exploit its mechanisms for providing SIP service = to=20 ordinary subscribers in order to provide a SIP trunking service to=20 PBXs.

- The mechanism SHOULD scale to PBXs of several thousand=20 AORs.

[JRE] The following was proposed by David Hancock and I = saw no=20 disagreement:
- The mechanism SHOULD scale to support several = thousand=20 IP-PBXs on a single service provider network.

- The mechanism = SHOULD=20 require relatively modest changes to a substantial population of = existing SSP=20 and PBX implementations, in order to encourage a fast market adoption = of the=20 standardized mechanism.

[JRE] The following proposal from Keith = was=20 discussed, but with no conclusion (or was Adam's objection not so much = to the=20 proposal but to Keith's subsequent assertion that it means no change = to the=20 Request-URI on an inbound request?):

- The mechanism SHOULD = allow=20 handling of inbound requests and outbound requests between SSP and PBX = to be=20 as common as possible as with a normal peering arrangement (RFC 3263 = based),=20 as far as the PBX is=20 = concerned.


John



-------------------------------= -------------------------=20
The information transmitted in this email and any of its = attachments is=20 intended only for the person or entity to which it is addressed and = may=20 contain Cablevision proprietary information, which is privileged,=20 confidential, or subject to copyright belonging to Cablevision. Any = review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon, this information by persons or entities other than the = intended=20 recipient is prohibited and may be unlawful. If you received this in = error,=20 please contact the sender immediately and delete and destroy the = communication=20 and all of the attachments you have received and all copies thereof.=20
--------------------------------------------------------

_______________________________________________
martini = mailing=20 = list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini=
------=_NextPart_000_1454_01CA9DCD.AE06FAF0-- From pkyzivat@cisco.com Mon Jan 25 13:02:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8F03A67DD for ; Mon, 25 Jan 2010 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjkDoeTE-7n8 for ; Mon, 25 Jan 2010 13:02:28 -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 22F4A3A67D7 for ; Mon, 25 Jan 2010 13:02:28 -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: ApoEACiWXUutJV2Z/2dsb2JhbADEWpYshDkE X-IronPort-AV: E=Sophos;i="4.49,342,1262563200"; d="scan'208";a="82068530" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2010 21:02:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0PL2YG1012607; Mon, 25 Jan 2010 21:02:34 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:02:34 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:02:33 -0600 Message-ID: <4B5E06DD.5010707@cisco.com> Date: Mon, 25 Jan 2010 16:02:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com> <4B5DFB74.80802@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 21:02:33.0930 (UTC) FILETIME=[B73462A0:01CA9E01] Cc: martini@ietf.org, Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:02:31 -0000 Spencer, I think the question you are asking is in some sense a non-issue, as it is entirely in control of the SSP. These all start out as user-info in URIs addressed to a domain the SSP is responsible for. It must overtly know that these are intended to be delegated to a customer. And part of knowing that can be knowing that they are phone numbers. The SSP could, if it wishes, also have another class of its own AORs that are *not* phone numbers, but that are also delegated to a customer. It might need a different rule for mapping these. A strong argument for the kind of mapping Adam is proposing is that the SSP might *not* represent phone numbers internally as E.164 numbers. And different SSPs might represent them differently. (I hate that, but gather it is the case.) And the PBX would perhaps like phone numbers all represented in some consistent way independent of SSP. Thanks, Paul Spencer Dawkins wrote: > Hi, Adam, > >>> How would we know that the user part is an E.164 number, >>> unambiguously, so that we don't have to reopen the discussion about >>> interpreting user parts (which doesn't sound like a short conversation)? >> >> I sure would be cool if we didn't have to worry about that, wouldn't >> it? Perhaps we should solve the general case instead of arguing about >> how to determine when the special case can be applied. > > Hi, Adam, > > My understanding here is that we are trying to figure out how the > service provider would automagically retarget +12145551212@sp.com (which > is directed to the service provider) to +12145551212@pbx.com (which is > directed to the PBX), where +12145551212 is an E.164 number that we can > know is an E.164 number, and not some SIP administrator's idea of a > cruel joke played on an unpleasant co-worker/customer). If I got this > wrong, please disabuse me. > > The limited approach, if we could make it work, would take advantage of > the global uniqueness of +12145551212 as an E.164 number, so that the > service provider would know it could safely retarget to > +12145551212@pbx.com. > > If we can't take advantage of the global uniqueness of +12145551212, > then there's no difference between retargeting +12145551212@sp.com and > retargeting spencer@sp.com, so we have to solve the general case to do > anything. > > Am I understanding your point of view correctly? > > Assuming so - I know that "if wishes were horses, then beggars would > ride". I have observed that sometimes, people do ride horses. I'm trying > to figure out if we could be riding horses, or if we're just wishing for > a pony... > > Thanks, > > Spencer - who probably should be speaking as co-chair on this, since > we're talking about making a decision that significantly affects the > work that MARTINI will do, but is trying to speak as an individual and > not speak in favor of one approach as chair. If I'm not succeeding, my > apologies for that. Bernard, please feel free to chime in if I'm doing > it wrong. > From BLINDSAY@nortel.com Mon Jan 25 13:24:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA583A68E1 for ; Mon, 25 Jan 2010 13:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.09 X-Spam-Level: X-Spam-Status: No, score=-5.09 tagged_above=-999 required=5 tests=[AWL=1.510, 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 XygwQcDVcb7r for ; Mon, 25 Jan 2010 13:24:11 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D56BA3A68D9 for ; Mon, 25 Jan 2010 13:24:10 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0PLO7O17538; Mon, 25 Jan 2010 21:24:08 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 16:23:54 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C3C82A9@zcarhxm1.corp.nortel.com> In-Reply-To: <4B5E06DD.5010707@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqeAcMKaIFmoOalQSia3mBESr0WhAAAI1QA References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DAD72.4050806@cisco.com><4B5DFB74.80802@nostrum.com> <4B5E06DD.5010707@cisco.com> From: "Brian Lindsay" To: "Paul Kyzivat" , "Spencer Dawkins" Cc: Hadriel Kaplan , martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:24:12 -0000 Hi, Note this isn't specific to MARTINI cases. Even if a pure "RFC3263" approach is being used for peering to a SIP PBX, the SSP would need to be able to re-target the request in the same fashion prior to routing the request (e.g. modify a request uri such as sip:+12145551212@sp.com;user=3Dphone to sip:+12145551212@pbx.com;user=3Dphone).=20 Regards Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Monday, January 25, 2010 4:02 PM To: Spencer Dawkins Cc: martini@ietf.org; Hadriel Kaplan Subject: Re: [martini] Requirements - rev1 Spencer, I think the question you are asking is in some sense a non-issue, as it is entirely in control of the SSP. These all start out as user-info in URIs addressed to a domain the SSP is responsible for. It must overtly know that these are intended to be delegated to a customer. And part of knowing that can be knowing that they are phone numbers. The SSP could, if it wishes, also have another class of its own AORs that are *not* phone numbers, but that are also delegated to a customer. It might need a different rule for mapping these. A strong argument for the kind of mapping Adam is proposing is that the SSP might *not* represent phone numbers internally as E.164 numbers. And different SSPs might represent them differently. (I hate that, but gather it is the case.) And the PBX would perhaps like phone numbers all represented in some consistent way independent of SSP. Thanks, Paul Spencer Dawkins wrote: > Hi, Adam, >=20 >>> How would we know that the user part is an E.164 number,=20 >>> unambiguously, so that we don't have to reopen the discussion about=20 >>> interpreting user parts (which doesn't sound like a short conversation)? >> >> I sure would be cool if we didn't have to worry about that, wouldn't=20 >> it? Perhaps we should solve the general case instead of arguing about >> how to determine when the special case can be applied. >=20 > Hi, Adam, >=20 > My understanding here is that we are trying to figure out how the=20 > service provider would automagically retarget +12145551212@sp.com=20 > (which is directed to the service provider) to +12145551212@pbx.com=20 > (which is directed to the PBX), where +12145551212 is an E.164 number=20 > that we can know is an E.164 number, and not some SIP administrator's=20 > idea of a cruel joke played on an unpleasant co-worker/customer). If I > got this wrong, please disabuse me. >=20 > The limited approach, if we could make it work, would take advantage=20 > of the global uniqueness of +12145551212 as an E.164 number, so that=20 > the service provider would know it could safely retarget to > +12145551212@pbx.com. >=20 > If we can't take advantage of the global uniqueness of +12145551212,=20 > then there's no difference between retargeting +12145551212@sp.com and > retargeting spencer@sp.com, so we have to solve the general case to do > anything. >=20 > Am I understanding your point of view correctly? >=20 > Assuming so - I know that "if wishes were horses, then beggars would=20 > ride". I have observed that sometimes, people do ride horses. I'm=20 > trying to figure out if we could be riding horses, or if we're just=20 > wishing for a pony... >=20 > Thanks, >=20 > Spencer - who probably should be speaking as co-chair on this, since=20 > we're talking about making a decision that significantly affects the=20 > work that MARTINI will do, but is trying to speak as an individual and > not speak in favor of one approach as chair. If I'm not succeeding, my > apologies for that. Bernard, please feel free to chime in if I'm doing > it wrong. >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From richard@shockey.us Mon Jan 25 14:17:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9E33A68F1 for ; Mon, 25 Jan 2010 14:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pxcyxNUpFmm8 for ; Mon, 25 Jan 2010 14:17:47 -0800 (PST) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id F24D93A67D7 for ; Mon, 25 Jan 2010 14:17:46 -0800 (PST) Received: (qmail 28768 invoked by uid 0); 25 Jan 2010 22:17:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 25 Jan 2010 22:17:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-Identified-User; b=hHtF9tjbPP1AOgwYn2CYRTcgLYFXSlucqyql+67sTGZxyIevSKNYhFn2yQX7iCn8K39+v4TrnP8jtYoSOC748gXyFz5eEat0L/M+aNq4pR91qoEhbHpClIC2ryRb8siU; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NZXFp-0008W5-4E; Mon, 25 Jan 2010 15:17:53 -0700 Message-ID: <4B5E1890.1010600@shockey.us> Date: Mon, 25 Jan 2010 17:17:52 -0500 From: Richard Shockey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Adam Roach References: <4B5DE388.3080604@nostrum.com> <4B5DEC7E.4000808@shockey.us> <4B5DF0B4.6000301@nostrum.com> In-Reply-To: <4B5DF0B4.6000301@nostrum.com> Content-Type: multipart/alternative; boundary="------------080302090401030906010505" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Cc: martini@ietf.org Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:17:48 -0000 This is a multi-part message in MIME format. --------------080302090401030906010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> >> I still wish folks would understand the underlying business issues >> that have driven folks to this point in the discussion. >> > > I fully understand how we got here. But MARTINI was not set up to > endorse a pre-existing practice as-is. I'm sure there are > organizations in this space that would be happy to rubber stamp vendor > solutions without proper technical vetting. We're not that. This is not a vendor specific solution. I did not think that existing 3GPP or TISPAN documented practice on implicit registration would qualify as rubber stamping. That remark is frankly a bit insulting even considering its source. > > I'm going to assume that the fact this landed in the IETF's lap is an > indication that the interested parties are seeking some level of IETF > imprimatur that the resulting technique is consistent with the > remainder of the protocol, and free of major security errors. To be blunt we needed the Option Tag which requires a RFC. The use of this methodology is IMHO consistent with 3261 and others on this list also believe that as well. In thousands of field deployments there have been no reported security issues .. confusion ..yes certainly . My principal concern at this moment is can the regex actually do what it is proposed to do and could be reasonably adopted by the relevant vendors and SSP that would use that even you are admiting that a REGISTER procedure properly defined would work. It is perfectly fair and reasonable to ask if a proposed IETF solution will actually deploy. In SIP and countless other instances there have been RFC adopted and no deployments due to a lack of proper understanding of actual operational conditions especially OSS/BSS issues those RFC's address. > > The deployed techniques don't qualify. I beg to differ. There is nothing wrong with the IETF adopting existing practice based on real field experience or incorporating it into the over all architecture if it can be demonstrated to work correctly. As it is now it does work but not as well as it should. Thats why we are having this excersise. You refuse to admit the possibility that a radical solution could be ignored. Humm sort of like health care reform? > The approaches simply have fundamental flaws that are too profound to > paper over with an option tag. I can appreciate the expedience of > addressing foundation problems by caulking the cracks in the walls, > but also recognize that you've done nothing to solve the underlying > problems when you do so. I just view the issue differently there is a problem in the field that needs to be fixed and fixed fast..there is a much larger issue of data provisioning in SIP networks that the IETF SIP community is not addressing correctly, hence this problem and many more to come. I certainly agree there is a much larger problem here that all of us have essentially created but is this the right time to tackle that meta problem. > You're effectively arguing that we need to ratify hodgepodge solutions > developed in the field or risk being ignored on this topic. I think > we're better off risking being ignored if the only other option is > blindly ratifying broken protocol extensions. Being ignored on this > topic may yield irrelevance on this one topic; ratifying broken > solutions leads to permanent irrelevance on all topics from now on. Well again I totally reject your contention that its "broken" or that shaken would some how "break" SIP that is just rhetoric. What we have now is some what cracked certainly but if the cure is worse than the disease than we haven't solved anything. > > /a -- Richard Shockey Shockey Consulting Chairman of Board SIP Forum Voice +1 703 593 2683 Skype etc : rshockey101 --------------080302090401030906010505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion.


I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that.

This is not a vendor specific solution. I did not think that existing 3GPP or TISPAN documented practice on implicit registration would qualify as rubber stamping.  That remark is frankly a bit insulting even considering its source.
 

I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors.

To be blunt we needed the Option Tag which requires a RFC.  The use of this methodology is IMHO consistent with 3261 and others on this list also believe that as well.  In thousands of field deployments there have been no reported security issues .. confusion ..yes certainly .  My principal concern at this moment is can the regex actually do what it is proposed to do and could be reasonably adopted by the relevant vendors and SSP that would use that even you are admiting that a REGISTER procedure properly defined would work.

It is perfectly fair and reasonable to ask if a proposed IETF solution will actually deploy. In SIP and countless other instances there have been RFC adopted and no deployments due to a lack of proper understanding of actual operational conditions especially OSS/BSS issues those RFC's address. 


The deployed techniques don't qualify.

I beg to differ. There is nothing wrong with the IETF adopting existing practice based on real  field experience or incorporating it into the over all architecture if it can be demonstrated to work correctly. As it is now it does work but not as well as it should. Thats why we are having this excersise.   You refuse to admit the possibility that a radical solution could be ignored. Humm sort of like health care reform?

The approaches simply have fundamental flaws that are too profound to paper over with an option tag. I can appreciate the expedience of addressing foundation problems by caulking the cracks in the walls, but also recognize that you've done nothing to solve the underlying problems when you do so.

I just view the issue differently there is a problem in the field that needs to be fixed and fixed fast..there is a much larger issue of data provisioning in SIP networks that the IETF SIP community is not addressing correctly,  hence this problem and many more to come. I certainly agree there is a much larger problem here that all of us have essentially created but is this the right time to tackle that meta problem.


You're effectively arguing that we need to ratify hodgepodge solutions developed in the field or risk being ignored on this topic. I think we're better off risking being ignored if the only other option is blindly ratifying broken protocol extensions. Being ignored on this topic may yield irrelevance on this one topic; ratifying broken solutions leads to permanent irrelevance on all topics from now on.

Well again I totally reject your contention that its "broken" or that shaken would some how "break" SIP that is just rhetoric.  What we have now is some what cracked certainly but if the cure is worse than the disease than we haven't solved anything.


/a

-- 
Richard Shockey
Shockey Consulting
Chairman of Board SIP Forum
Voice +1 703 593 2683
Skype etc : rshockey101
--------------080302090401030906010505-- From jsburton@cablevision.com Mon Jan 25 14:43:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB233A6452 for ; Mon, 25 Jan 2010 14:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 XAxsiVW--FVu for ; Mon, 25 Jan 2010 14:43:50 -0800 (PST) Received: from cscpsmout01.cablevision.com (cscpsmout01.cablevision.com [167.206.119.144]) by core3.amsl.com (Postfix) with ESMTP id 7F25E3A68BE for ; Mon, 25 Jan 2010 14:43:49 -0800 (PST) Received: from c3gwiaoutvs.cablevision.com (c3gwiaoutvs.cablevision.com [10.128.36.189]) by cscpsmout01.cablevision.com (Sentrion-MTA-4.0.2/Sentrion-MTA-4.0.2) with ESMTP id o0PMhu43011008 for ; Mon, 25 Jan 2010 17:43:56 -0500 X-DKIM: Sendmail DKIM Filter v2.5.6 cscpsmout01.cablevision.com o0PMhu43011008 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cablevision.com; s=cscprod; t=1264459436; bh=RXUC1oO1wE6o4hIqybfwSNmBlkpKH/H+v1DkuX1 CZAw=; h=Message-Id:Date:From:To:Subject:Mime-Version:Content-Type; b=4dXIgbmXTOXv4C0aFcKUo1DVm2BSV6d/udOQ09f4OfNprQ2Sg+YfCx4PS4rO02Gsg E4YIBWuVxo+kYfjk5YlPyjQwP7CHVymw6tfkianTIhAycY7YYgZq1x1/8vmi8MOEfRi 0kjenNkaDf4TeSkHxt+EOO3JPzKov3yXu5bJrrs= Received: from C3GWIAOUTDOM-MTA by c3gwiaoutvs.cablevision.com with Novell_GroupWise; Mon, 25 Jan 2010 17:43:56 -0500 Message-Id: <4B5DAE26.6D98.00CB.0@cablevision.com> X-Mailer: Novell GroupWise Internet Agent 7.0.3 Date: Mon, 25 Jan 2010 17:43:50 -0500 From: "Jack Burton" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD5FFCDB6.0__=" X-Auth-Type: Internal IP Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:43:52 -0000 --=__PartD5FFCDB6.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I tried replying earlier, but I think I had the address messed up. I totally agree with Richard's comments. When does a standards organization loose relevance? I would argue that happens when its standards are not put into practice. REGISTER is how the IP-PBX SIP Trunking world works today, and in SIPConnect we hope to make that work more consistently among vendors. SSPs (and probably equipment vendors as well) would never implement PUBLISH because doing so could break what they are doing today. They would continue in the "hodgepodge" of an ill-defined Registration method. -Jack >>> Richard Shockey 1/25/2010 14:17 >>> I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion. I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that. This is not a vendor specific solution. I did not think that existing 3GPP or TISPAN documented practice on implicit registration would qualify as rubber stamping. That remark is frankly a bit insulting even considering its source. I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors. To be blunt we needed the Option Tag which requires a RFC. The use of this methodology is IMHO consistent with 3261 and others on this list also believe that as well. In thousands of field deployments there have been no reported security issues .. confusion ..yes certainly . My principal concern at this moment is can the regex actually do what it is proposed to do and could be reasonably adopted by the relevant vendors and SSP that would use that even you are admiting that a REGISTER procedure properly defined would work. It is perfectly fair and reasonable to ask if a proposed IETF solution will actually deploy. In SIP and countless other instances there have been RFC adopted and no deployments due to a lack of proper understanding of actual operational conditions especially OSS/BSS issues those RFC's address. The deployed techniques don't qualify. I beg to differ. There is nothing wrong with the IETF adopting existing practice based on real field experience or incorporating it into the over all architecture if it can be demonstrated to work correctly. As it is now it does work but not as well as it should. Thats why we are having this excersise. You refuse to admit the possibility that a radical solution could be ignored. Humm sort of like health care reform? The approaches simply have fundamental flaws that are too profound to paper over with an option tag. I can appreciate the expedience of addressing foundation problems by caulking the cracks in the walls, but also recognize that you've done nothing to solve the underlying problems when you do so. I just view the issue differently there is a problem in the field that needs to be fixed and fixed fast..there is a much larger issue of data provisioning in SIP networks that the IETF SIP community is not addressing correctly, hence this problem and many more to come. I certainly agree there is a much larger problem here that all of us have essentially created but is this the right time to tackle that meta problem. You're effectively arguing that we need to ratify hodgepodge solutions developed in the field or risk being ignored on this topic. I think we're better off risking being ignored if the only other option is blindly ratifying broken protocol extensions. Being ignored on this topic may yield irrelevance on this one topic; ratifying broken solutions leads to permanent irrelevance on all topics from now on. Well again I totally reject your contention that its "broken" or that shaken would some how "break" SIP that is just rhetoric. What we have now is some what cracked certainly but if the cure is worse than the disease than we haven't solved anything. /a -- Richard Shockey Shockey Consulting Chairman of Board SIP Forum Voice +1 703 593 2683 Skype etc : rshockey101 -------------------------------------------------------- The information transmitted in this email and any of its attachments is intended only for the person or entity to which it is addressed and may contain Cablevision proprietary information, which is privileged, confidential, or subject to copyright belonging to Cablevision. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete and destroy the communication and all of the attachments you have received and all copies thereof. -------------------------------------------------------- --=__PartD5FFCDB6.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
I tried replying earlier, but I think I had the address messed up.
 
I totally agree with Richard's comments.  When does a standards o= rganization loose relevance?  I would argue that happens when its stan= dards are not put into practice.
 
REGISTER is how the IP-PBX SIP Trunking world works today, and in SIPC= onnect we hope to make that work more consistently among vendors. = ; SSPs (and probably equipment vendors as well) would never implement PUBLI= SH because doing so could break what they are doing today.  They would= continue in the "hodgepodge" of an ill-defined Registration method.
 
-Jack

>>> Richard Shockey <richard@shockey.us> 1/25/2010 = 14:17 >>>


I stil= l wish folks would understand the underlying business issues that have driv= en folks to this point in the discussion.


I fully = understand how we got here. But MARTINI was not set up to endorse a pre-exi= sting practice as-is. I'm sure there are organizations in this space that w= ould be happy to rubber stamp vendor solutions without proper technical vet= ting. We're not that.

This is not a vendor specific sol= ution. I did not think that existing 3GPP or TISPAN documented practice on = implicit registration would qualify as rubber stamping.  That remark i= s frankly a bit insulting even considering its source.
 

I'm g= oing to assume that the fact this landed in the IETF's lap is an indication= that the interested parties are seeking some level of IETF imprimatur that= the resulting technique is consistent with the remainder of the protocol, = and free of major security errors.

To be blunt we neede= d the Option Tag which requires a RFC.  The use of this methodology is= IMHO consistent with 3261 and others on this list also believe that as wel= l.  In thousands of field deployments there have been no reported secu= rity issues .. confusion ..yes certainly .  My principal concern at th= is moment is can the regex actually do what it is proposed to do and could = be reasonably adopted by the relevant vendors and SSP that would use that e= ven you are admiting that a REGISTER procedure properly defined would work.=

It is perfectly fair and reasonable to ask if a proposed IETF solu= tion will actually deploy. In SIP and countless other instances there have = been RFC adopted and no deployments due to a lack of proper understanding o= f actual operational conditions especially OSS/BSS issues those RFC's addre= ss. 


The d= eployed techniques don't qualify.

I beg to differ. There is= nothing wrong with the IETF adopting existing practice based on real = field experience or incorporating it into the over all architecture if it = can be demonstrated to work correctly. As it is now it does work but not as= well as it should. Thats why we are having this excersise.   You refu= se to admit the possibility that a radical solution could be ignored. Humm = sort of like health care reform?

The appro= aches simply have fundamental flaws that are too profound to paper over wit= h an option tag. I can appreciate the expedience of addressing foundation p= roblems by caulking the cracks in the walls, but also recognize that you've= done nothing to solve the underlying problems when you do so.

I just view the issue differently there is a problem in the field t= hat needs to be fixed and fixed fast..there is a much larger issue of data = provisioning in SIP networks that the IETF SIP community is not addressing = correctly,  hence this problem and many more to come. I certainly agre= e there is a much larger problem here that all of us have essentially creat= ed but is this the right time to tackle that meta problem.


You're ef= fectively arguing that we need to ratify hodgepodge solutions developed in = the field or risk being ignored on this topic. I think we're better off ris= king being ignored if the only other option is blindly ratifying broken pro= tocol extensions. Being ignored on this topic may yield irrelevance on this= one topic; ratifying broken solutions leads to permanent irrelevance on al= l topics from now on.

Well again I totally reject your = contention that its "broken" or that shaken would some how "break" SIP that= is just rhetoric.  What we have now is some what cracked certainly bu= t if the cure is worse than the disease than we haven't solved anything.

/a

--=20
Richard Shockey
Shockey Consulting
Chairman of Board SIP Forum
Voice +1 703 593 2683
Skype etc : rshockey101

--------------------------------------------------------
The information transmitted in this email and any of its attachments is int= ended only for the person or entity to which it is addressed and may contai= n Cablevision proprietary information, which is privileged, confidential, o= r subject to copyright belonging to Cablevision. Any review, retransmission= , dissemination or other use of, or taking of any action in reliance upon, = this information by persons or entities other than the intended recipient i= s prohibited and may be unlawful. If you received this in error, please con= tact the sender immediately and delete and destroy the communication and al= l of the attachments you have received and all copies thereof.
-------------------------------------------------------- --=__PartD5FFCDB6.0__=-- From spencer@wonderhamster.org Mon Jan 25 14:44:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CD23A67D7 for ; Mon, 25 Jan 2010 14:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 keeFXup1Sj5g for ; Mon, 25 Jan 2010 14:44:53 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 00A6C3A6452 for ; Mon, 25 Jan 2010 14:44:53 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MgKlC-1NBwFp02kg-00NiUg; Mon, 25 Jan 2010 17:44:54 -0500 Message-ID: <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" , "Adam Roach" References: <4B5DD8D3.5050705@cisco.com> <4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> Date: Mon, 25 Jan 2010 16:44:45 -0600 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+NR0vI8N6maGm11ruz71XEIFC5k/mkvboHcWR L8ouT6Zatailnm3nWQ6LoOVFallUzgSuePzBu9Qpye/wp3wW/N l0UEa32qXemNDObdTeWG4RWTVifYcpSqxfqaFFtHsg= Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:44:54 -0000 Hi, Paul, >>> The wildcard proposals certainly attempt to compress the encoding, but >>> in general those only work if the majority of the AORs have some textual >>> commonalities that can be exploited. But while that is the norm, there >>> are no guarantees that a pbx might not have 100 distinct phone numbers >>> that have no patterned relationship that can be exploited via regular >>> expressions to encode the full set concisely. >> >> Is this really a requirement? It seems a bit of a tortured use case. > > I don't know what sort of tortured cases exist out there in the wild. > > I'm not arguing for anything specific. I'm just trying to understand the > requirements proposed. If its "support up to N distinct AORs and/or > AOR-ranges" where an AOR-range is suitably defined, then we can discuss > what a suitable value of N might be, and it may be small. But if its > "support up to N distinct AORs" with no restriction on what they might be > then I think we will find a requirement for a larger value of N. > > Thanks, > Paul (Caveat - I try to be pretty clear in my mind about when I'm speaking as an individual who is also SIP Forum's editor for SIPconnect 1.1 and when I'm wearing an IETF hat as MARTINI co-chair, but if you think I may be confused about that, please feel free to ask/challenge - it's not easy, and I won't be offended if someone helps me distinguish on a specific point) Speaking as an individual, but from my perspective as SIPconnect 1.1 editor... After much jumping up and down by all interested parties, the current draft version of SIPconnect 1.1 explicitly prefers operation over TCP. The SIPconnect 1.1 team made this decision to accommodate a variety of SIP extensions that, taken together, are moving SIP request/response sizes closer to the maximum message size for SIP over UDP (as has been discussed at length on SIP-related IETF mailing lists). Note that this preference has nothing to do with passing information about distinct AORs around at REGISTER time, because SIPconnect 1.1 doesn't assume that's happening at all - it might be lovely to pass this information around, but it isn't in SIPconnect 1.1 today. So, at some level, the SIPconnect 1.1 guys don't care about the number of AORs supported, because their preferred answer is that if you're doing TCP and you decide to start passing complete information about distinct AORs in either direction, you can do that without worrying about request/response sizes. If people in MARTINI are willing to "go there", then we don't need to worry about mandating support for N distict AORs in MARTINI. If people in MARTINI are unwilling to "go there", I'd suggest that we be very intentional about what the requirement for passing information about the AORs that have been MARTINIed might be - because if we have to do this, and have to define it so that it works over UDP, that's going to be a painful discussion. I am especially unexcited about this if MARTINI ends up describing a regex syntax, because that could lead to situations where you could register all your AORs over UDP using a regex expression, but then four of your customers renumber out of that numbering block and now you need to include additional expressions, which puts you over the UDP request/response size :-( Again, I'm providing background as SIPconnect 1.1 editor here, which qualifies me to speak as an individual, but nothing more - so please feel free to tell the working group what you really think. Spencer From eburger@standardstrack.com Mon Jan 25 14:48:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47873A63C9 for ; Mon, 25 Jan 2010 14:48:10 -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 hjgdY5R7HChp for ; Mon, 25 Jan 2010 14:48:10 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 21DAD3A6929 for ; Mon, 25 Jan 2010 14:48:10 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.178]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NZXj9-0001UL-Df for martini@ietf.org; Mon, 25 Jan 2010 14:48:11 -0800 Message-Id: From: Eric Burger To: martini@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: Mon, 25 Jan 2010 17:48:14 -0500 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: [martini] Help? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:48:10 -0000 I am having trouble understanding what the issues are in the proposed draft. I am seeing a lot of list traffic about "this is broken" and "that is broken." However, I do not get what "this" or "that" is. Can anyone help me on this? Thanks. From adam@nostrum.com Mon Jan 25 14:50:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7C73A6930 for ; Mon, 25 Jan 2010 14:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.058, 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 n7gyPnDQUXgg for ; Mon, 25 Jan 2010 14:50:26 -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 F1ADF3A692F for ; Mon, 25 Jan 2010 14:50:25 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0PMoOwI040183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 16:50:26 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5E2030.2040306@nostrum.com> Date: Mon, 25 Jan 2010 16:50:24 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jack Burton References: <4B5DAE26.6D98.00CB.0@cablevision.com> In-Reply-To: <4B5DAE26.6D98.00CB.0@cablevision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:50:27 -0000 On 1/25/10 4:43 PM, Jack Burton wrote: > REGISTER is how the IP-PBX SIP Trunking world works today, and in > SIPConnect we hope to make that work more consistently among vendors. > SSPs (and probably equipment vendors as well) would never implement > PUBLISH because doing so could break what they are doing today. Don't get hung up on martini-up's proposal to use PUBLISH. While it does solve a very real class of problems, that one relatively minor aspect of the draft is not the most important mechanism it proposes. The majority of the problems it solves involve the explicit signaling of AORs in the request, the definition of a mechanism that enables "one contact URI per AOR," and the congruence with previous uses of REGISTER by employing "contact routing" instead of "domain routing." /a From spencer@wonderhamster.org Mon Jan 25 14:54:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6D33A6917 for ; Mon, 25 Jan 2010 14:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 NhBNNHQSQove for ; Mon, 25 Jan 2010 14:54:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 95BB43A6834 for ; Mon, 25 Jan 2010 14:54:14 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MAyFQ-1NhDKv1jpU-009xqS; Mon, 25 Jan 2010 17:54:20 -0500 Message-ID: From: "Spencer Dawkins" To: "Paul Kyzivat" , "Adam Roach" References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> Date: Mon, 25 Jan 2010 16:54:11 -0600 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/EX0zsO2BKQkt+hP4135xE++DdWdl1fkNeX+9 ZXCHsJUUwRad1P9QLuEjDFOGd7069sDN5vFDHGhEATkBCHA3Xk Rz2wXsRoQxORfdFf7ShZyqCXZ9RnhsK+RhcTPSeR1E= Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:54:15 -0000 Dorks follow up to their own posts - my apologies for being a dork, but ... > If people in MARTINI are willing to "go there", then we don't need to > worry about mandating support for N distict AORs in MARTINI. > > If people in MARTINI are unwilling to "go there", I'd suggest that we be > very intentional about what the requirement for passing information about > the AORs that have been MARTINIed might be - because if we have to do > this, and have to define it so that it works over UDP, that's going to be > a painful discussion. > > I am especially unexcited about this if MARTINI ends up describing a regex > syntax, because that could lead to situations where you could register all > your AORs over UDP using a regex expression, but then four of your > customers renumber out of that numbering block and now you need to include > additional expressions, which puts you over the UDP request/response size > :-( I don't want to leave this thought where it can be taken out of context - I actually LIKE the idea of regex or some other compression mechanism if information about distinct AORs is being passed back and forth. I understand the point Richard makes about numbering block pollution, but IMO it's worth looking at this and deciding if there's a compression mechanism that would still be useful when numbering blocks are polluted. What I'm not excited about is the interaction between regex et al and UDP transport, and the resulting opportunity for things that once worked starting to fail - that's what I was intending to say. Spencer, speaking as a dork ... From pkyzivat@cisco.com Mon Jan 25 15:40:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C883A6820 for ; Mon, 25 Jan 2010 15:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsmxOhJUMduT for ; Mon, 25 Jan 2010 15:40: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 7E44F3A680A for ; Mon, 25 Jan 2010 15:40: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: ApoEAJ66XUtAZnwM/2dsb2JhbADDApZQhDkE X-IronPort-AV: E=Sophos;i="4.49,342,1262563200"; d="scan'208";a="82090821" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jan 2010 23:40:41 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.174]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0PNefEk024931; Mon, 25 Jan 2010 23:40:41 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:40:41 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:40:41 -0600 Message-ID: <4B5E2C00.4050407@cisco.com> Date: Mon, 25 Jan 2010 18:40:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2010 23:40:41.0499 (UTC) FILETIME=[CE3C86B0:01CA9E17] Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:40:35 -0000 Spencer, I guess this needs to be segmented into separate issues, which you have already more or less done: - do the AORs need to be communicated at all in the REGISTER? - if the AORs do need to be communicated in the REGISTER: - in request or response? - does this mechanism have to work for UDP, or only for TCP? - even with TCP, how big of a message is acceptable? - Will contact routing or loose routing be used? - If contact routing, - how will the prior r-uri be communicated? - if by manipulating the the registered contact, how is that defined? (And how is it discovered after the fact?) I hear some saying that the AORs need to be communicated because the P-CSCF needs them. I hear others saying they need to be communicated because otherwise there are problems keeping pbx and SSP in sync, or in cases where support for one AOR may move between pbxes for the same "customer". I hear others saying "we don't need no stinking list of AORs, its all provisioned anyway, and that's the way we like it." And *maybe* I'm hearing some saying "we don't need to mention communicating the AORs in *this* draft - send them if you like, or don't." (I don't buy this - it presents significant interop problems.) Thanks, Paul Spencer Dawkins wrote: > Dorks follow up to their own posts - my apologies for being a dork, but ... > >> If people in MARTINI are willing to "go there", then we don't need to >> worry about mandating support for N distict AORs in MARTINI. >> >> If people in MARTINI are unwilling to "go there", I'd suggest that we >> be very intentional about what the requirement for passing information >> about the AORs that have been MARTINIed might be - because if we have >> to do this, and have to define it so that it works over UDP, that's >> going to be a painful discussion. >> >> I am especially unexcited about this if MARTINI ends up describing a >> regex syntax, because that could lead to situations where you could >> register all your AORs over UDP using a regex expression, but then >> four of your customers renumber out of that numbering block and now >> you need to include additional expressions, which puts you over the >> UDP request/response size :-( > > I don't want to leave this thought where it can be taken out of context > - I actually LIKE the idea of regex or some other compression mechanism > if information about distinct AORs is being passed back and forth. I > understand the point Richard makes about numbering block pollution, but > IMO it's worth looking at this and deciding if there's a compression > mechanism that would still be useful when numbering blocks are polluted. > > What I'm not excited about is the interaction between regex et al and > UDP transport, and the resulting opportunity for things that once worked > starting to fail - that's what I was intending to say. > > Spencer, speaking as a dork ... > From D.Hancock@CableLabs.com Mon Jan 25 15:57:37 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C633A67EA for ; Mon, 25 Jan 2010 15:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be+ojy9xjBZW for ; Mon, 25 Jan 2010 15:57:36 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id B7D5E3A6768 for ; Mon, 25 Jan 2010 15:57:36 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id o0PNvint001597; Mon, 25 Jan 2010 16:57:44 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 25 Jan 2010 16:57:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 25 Jan 2010 16:57:44 -0700 From: David Hancock To: Spencer Dawkins , "Elwell, John" , "martini@ietf.org" Date: Mon, 25 Jan 2010 16:57:42 -0700 Thread-Topic: [martini] Evaluation of issues solved by martini-up Thread-Index: Acqd4EJZqMHtrNrNSQuNhs4cZ3/vYgAIDvKQ Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD37AFE76@srvxchg> References: <40403A0B0ABC40388E1BCED3C4776EC0@china.huawei.com> In-Reply-To: <40403A0B0ABC40388E1BCED3C4776EC0@china.huawei.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-Approved: ondar Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:57:37 -0000 Spencer, Regarding your second question below on avalanche restarts... One of the reasons SIP Service Providers prefer a registration-based approa= ch is that it is built on a well-proven SIP mechanism that has been tuned t= o support millions of users. From the SSP's perspective it's much less risk= y to reuse an existing mechanism that's had the benefit of years of increme= ntal improvements in real-world deployments, than to go with a new & unprov= en mechanism -- especially when the new mechanism basically does the same t= hing (binds AoRs to location).=20 For example, our PacketCable specifications mandate some "value add" proced= ures for registering endpoints (including registering IP-PBXs) to support t= he following: - minimize network overload when a large number of endpoints need to regis= ter simultaneously (avalanche restart) - minimize the service outage when a component in the registered service-r= oute/path fails (e.g., the currently assigned edge-proxy fails) RFC3261 is pretty light on these procedures. Here's a sample of text from s= ection 10.2.7... ------ RFC3261 section 10.2.7 ------ If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately re-attempt a registration to the same registrar. An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated. ------ RFC3261 section 10.2.7 ------ The following is a sample of additional endpoint procedures mandated in Pac= ketCable specs to support avalanche restart and to minimize service interru= ption on SP network failure. Protect network from avalanche restart: PacketCable specifies that when repeated initial registration attempts fail= (say due to no response, or on failure response 4xx (except 401, etc), 5xx= , 6xx response), the endpoint must implement an exponential backoff delay u= sing an algorithm similar to that specified in section 4.5 of the Outbound = RFC. The Service Provider can configure the base-time and max-time values s= o they're tuned to meet the specific needs of the network. The SP network c= an also send a Retry-After header to override these backoff delay intervals= , if needed.=20 Minimize service outage: A PacketCable SIP endpoint is configured with the FQDN of the edge-proxy in= the SP network that it must use to gain access to the network. The endpoin= t resolves this FQDN to multiple IP addresses via DNS, and selects one of t= he IP addresses to establish a TLS session and register with the network (t= he network authenticates the REGISTER request, etc). All SIP messages betwe= en the network and SIP endpoint are sent over the established TLS session. = If the endpoint receives a failure on a subsequent registration refresh att= empt (4xx (except 401), 5xx, 6xx, Timer-F) it releases all resources associ= ated with the existing (now failed) registration, and attempts to register = again via a new edge-proxy IP address, using the backoff procedure describe= d above.=20 Additional registration procedures are mandated for the core network compon= ents (e.g., spreading the registration load across multiple S-CSCFs, etc). = Plus, local operator policy may dictate additional special procedures to su= pport these use-cases. These procedures would obviously not apply as specif= ied to a PUBLISH-based approach. Since we haven't described the mechanism i= n detail, it's not clear to me if/how these procedures would apply if the m= artini-up solution is carried in a REGISTER request, instead of PUBLISH.=20 Thanks David > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Monday, January 25, 2010 10:03 AM > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] Evaluation of issues solved by martini-up >=20 > (as co-chair) >=20 > To John, >=20 > Thanks for walking through these points - it's helpful. >=20 > (as individual) >=20 > To all, but especially to Adam, >=20 > I've heard two assertions offlist that I wanted to bring on-list before > tomorrow's call, so that people have a chance to check their own > products/networks, think, and perform other active verbs, before we > talk... >=20 > Someone pointed out to me that using SBCs to drop traffic that doesn't > correspond to an active registration is a fairly widespread practice for > providers who support small PBXs today. If this is the case, we would be > creating a dependency that this filtering change if we use a solution > based > on PUBLISH, Dean's proposed RUPDATE, etc. >=20 > Someone pointed out to me that carriers special-case avalanche restart > procedures for REGISTER. Again, this would have to change if we adopt a > solution based on PUBLISH, Dean's proposed RUPDATE, etc. >=20 > Thanks, >=20 > Spencer >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Mon Jan 25 16:02:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0323A6820 for ; Mon, 25 Jan 2010 16:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 nbBc7YG2Zhh5 for ; Mon, 25 Jan 2010 16:02:38 -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 1C96D3A6810 for ; Mon, 25 Jan 2010 16:02:37 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0Q02hj1046013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 18:02:44 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5E3123.5070906@nostrum.com> Date: Mon, 25 Jan 2010 18:02:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Richard Shockey References: <4B5DE388.3080604@nostrum.com> <4B5DEC7E.4000808@shockey.us> <4B5DF0B4.6000301@nostrum.com> <4B5E1890.1010600@shockey.us> In-Reply-To: <4B5E1890.1010600@shockey.us> Content-Type: multipart/alternative; boundary="------------010208070004010508030503" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Evaluation of issues solved by martini-up X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 00:02:40 -0000 This is a multi-part message in MIME format. --------------010208070004010508030503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/25/10 4:17 PM, Richard Shockey wrote: > >>> >>> I still wish folks would understand the underlying business issues >>> that have driven folks to this point in the discussion. >>> >> >> I fully understand how we got here. But MARTINI was not set up to >> endorse a pre-existing practice as-is. I'm sure there are >> organizations in this space that would be happy to rubber stamp >> vendor solutions without proper technical vetting. We're not that. > > This is not a vendor specific solution. I did not think that existing > 3GPP or TISPAN documented practice on implicit registration would > qualify as rubber stamping. How is showing up at the IETF with a solution and refusing to compromise on any of the details of that solution while seeking an RFC number anything but that? Regardless of the pedigree of the solution (and we've tried to explain how this proposal differs materially from 3GPP implicit registration, so that hardly applies anyway), it's asking for an endorsement without accepting input. You can call it whatever you want -- ratification, rubber stamping, blind publication -- but it's not my understanding of how the IETF works. >> I'm going to assume that the fact this landed in the IETF's lap is an >> indication that the interested parties are seeking some level of IETF >> imprimatur that the resulting technique is consistent with the >> remainder of the protocol, and free of major security errors. > > > To be blunt we needed the Option Tag which requires a RFC. The _reason_ an option tag requires an RFC is to ensure that the corresponding solution has had proper review by experts inside the IETF. I've been at this long enough and have contributed enough to this protocol overall that I am bold enough to consider myself in that category. I don't claim to be any kind of final authority on the topic, but you'll notice other people who have the proper credentials to hold themselves out as experts as well are objecting to the solution brought to us also, most of them for the same reasons -- or at least a subset of the reasons -- that I've pointed out myself. >> The deployed techniques don't qualify. > > I beg to differ. There is nothing wrong with the IETF adopting > existing practice based on real field experience or incorporating it > into the over all architecture if it can be demonstrated to work > correctly. It works correctly in certain architectures. It breaks in others. It has some rather severe security shortcomings that Dean has gone through the trouble of detailing. These won't show up in most walled gardens, but they can cause real problems in public networks. It creates an alternative system to name resolution other than DNS, which runs counter to stated IAB and ICANN positions on the topic. It pretty much destroys any chance of getting GRUUs to work through PBXes, which eliminates entire classes of cross-domain services. This list is not exhaustive: there are a host of issues -- technical, architectural, and political -- that make the solution that was brought to the IETF inadvisable. Just because it works in certain architectures under certain circumstances does not mean that we can sign off on it for general use on the Internet. And, frankly, if the IETF used "working existing practice" as its sole criteria, we would have slapped an RFC number on CU-SeeMe's audio-video protocol back in 1994 and called it a day. /a --------------010208070004010508030503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/25/10 4:17 PM, Richard Shockey wrote:


I still wish folks would understand the underlying business issues that have driven folks to this point in the discussion.


I fully understand how we got here. But MARTINI was not set up to endorse a pre-existing practice as-is. I'm sure there are organizations in this space that would be happy to rubber stamp vendor solutions without proper technical vetting. We're not that.

This is not a vendor specific solution. I did not think that existing 3GPP or TISPAN documented practice on implicit registration would qualify as rubber stamping.

How is showing up at the IETF with a solution and refusing to compromise on any of the details of that solution while seeking an RFC number anything but that? Regardless of the pedigree of the solution (and we've tried to explain how this proposal differs materially from 3GPP implicit registration, so that hardly applies anyway), it's asking for an endorsement without accepting input. You can call it whatever you want -- ratification, rubber stamping, blind publication -- but it's not my understanding of how the IETF works.

I'm going to assume that the fact this landed in the IETF's lap is an indication that the interested parties are seeking some level of IETF imprimatur that the resulting technique is consistent with the remainder of the protocol, and free of major security errors.


To be blunt we needed the Option Tag which requires a RFC.

The _reason_ an option tag requires an RFC is to ensure that the corresponding solution has had proper review by experts inside the IETF. I've been at this long enough and have contributed enough to this protocol overall that I am bold enough to consider myself in that category. I don't claim to be any kind of final authority on the topic, but you'll notice other people who have the proper credentials to hold themselves out as experts as well are objecting to the solution brought to us also, most of them for the same reasons -- or at least a subset of the reasons -- that I've pointed out myself.

The deployed techniques don't qualify.

I beg to differ. There is nothing wrong with the IETF adopting existing practice based on real  field experience or incorporating it into the over all architecture if it can be demonstrated to work correctly.

It works correctly in certain architectures. It breaks in others. It has some rather severe security shortcomings that Dean has gone through the trouble of detailing. These won't show up in most walled gardens, but they can cause real problems in public networks. It creates an alternative system to name resolution other than DNS, which runs counter to stated IAB and ICANN positions on the topic. It pretty much destroys any chance of getting GRUUs to work through PBXes, which eliminates entire classes of cross-domain services. This list is not exhaustive: there are a host of issues -- technical, architectural, and political -- that make the solution that was brought to the IETF inadvisable. Just because it works in certain architectures under certain circumstances does not mean that we can sign off on it for general use on the Internet.

And, frankly, if the IETF used "working existing practice" as its sole criteria, we would have slapped an RFC number on CU-SeeMe's audio-video protocol back in 1994 and called it a day.

/a
--------------010208070004010508030503-- From bernard_aboba@hotmail.com Mon Jan 25 19:24:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0099C3A68E5 for ; Mon, 25 Jan 2010 19:24:15 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_20=-0.74] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT5oKDlO+HVS for ; Mon, 25 Jan 2010 19:24:14 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1264476254-7657-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id D8A713A6895 for ; Mon, 25 Jan 2010 19:24:13 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 19:24:22 -0800 Message-ID: From: "Bernard Aboba" To: Date: Mon, 25 Jan 2010 19:24:22 -0800 X-Mailer: Microsoft Outlook 14.0 Subject: [martini] MARTINI Service Provider Protection Program X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 03:24:15 -0000 This is a multi-part message in MIME format... ------------=_1264476254-7657-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1264476254-7657-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id D8A713A6895 for ; Mon, 25 Jan 2010 19:24:13 -0800 (PST) Received: from BLU137-DS1 ([65.55.111.73]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 19:24:22 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: MARTINI Service Provider Protection Program Date: Mon, 25 Jan 2010 19:24:22 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0036_01CA9DF3.FFCB7CA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGWoXvAqJYstUZbGpvy5AM/viNslA== X-MS-TNEF-Correlator: 00000000B7DA8EB0AE7AC24184A8151FF4B0FB95070064E51AECD354544EB78CB7421E00090D00000001E1E900001F360934CC25714EA252290083BACC8E0000234269A30000 Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 03:24:22.0327 (UTC) FILETIME=[0DAC5C70:01CA9E37] ------=_NextPart_000_0036_01CA9DF3.FFCB7CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard Shockey said: "But I will leave it to representatives of SSP's to comment on that directly, because in the final analysis its the SSP that will have to live with the MARTINI solution. " [BA] If there are any service providers on this mailing list, I would like to encourage them to speak to this question. We had reserved time on the agenda during Virtual Interim II tomorrow for "Service Provider Perspectives".... But it's not clear that we have yet located service provider(s) to fill the slot. How sad is that? If there is a Service Provider within reach of this message who would be interested in speaking at the Interim tomorrow, please contact Spencer and/or myself. If you are afraid to be associated with the MARTINI WG, we probably can arrange some sort of identity protection. ------=_NextPart_000_0036_01CA9DF3.FFCB7CA0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhYDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBIDwAAKgAAAAsAAgABAAAAAwAmAAAAAAALACkAAAAAAB4A cAABAAAALAAAAE1BUlRJTkkgU2VydmljZSBQcm92aWRlciBQcm90ZWN0aW9uIFByb2dyYW0AAgFx AAEAAAAWAAAAAQGWoXvAqJYstUZbGpvy5AM/viNslAAACwABDgAAAAACAQoOAQAAAC4AAAAAAAAA cX15PG3bvEGuCHn+sTld+wEA2VOcImGmu0W52rYscIGzwQEAJAD//wAAAAADABQOAQAAAAIBFDQB AAAAEAAAAFSUocApfxAbpYcIACsqJRcDAA80/T+tDh4AATABAAAADgAAAEJlcm5hcmQgQWJvYmEA AAAeAAMwAQAAABoAAABiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tAAAACwAWMAEAAAADAN4/n04A AAMA8T8JBAAAHgD6PwEAAAAOAAAAQmVybmFyZCBBYm9iYQAAAAMAAlkAABYAAwAJWQIAAAALABRo AAAAAAIB42UBAAAAFQAAABS11YGFHReFTbk7Ij9SzVPOAAA0UwAAAAIB4mUBAAAAFAAAALXVgYUd F4VNuTsiP1LNU84AADRTAwAUgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALACCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAMAdYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwCm gAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAKiACCAGAAAAAADAAAAAAAAARgAAAAAOhQAA AAAAAAMAq4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgGxgAggBgAAAAAAwAAAAAAAAEYA AAAAIIUAAAEAAABkAQAAAgEEAAAAAAAAAAVSZXBseQhJUE0uTm90ZQdNZXNzYWdlAlJFBQAAAAAA AAAAAQAAAAAAAAACAAAAZgAAAAIAAAABAAAADFJlcGx5IHRvIEFsbAhJUE0uTm90ZQdNZXNzYWdl AlJFBQAAAAAAAAAAAQAAAAAAAAACAAAAZwAAAAMAAAACAAAAB0ZvcndhcmQISVBNLk5vdGUHTWVz c2FnZQJGVwUAAAAAAAAAAAEAAAAAAAAAAgAAAGgAAAAEAAAAAwAAAA9SZXBseSB0byBGb2xkZXII SVBNLlBvc3QEUG9zdAAFAAAAAAAAAAABAAAAAAAAAAIAAABsAAAACAAAAAQBBVIAZQBwAGwAeQAC UgBFAAxSAGUAcABsAHkAIAB0AG8AIABBAGwAbAACUgBFAAdGAG8AcgB3AGEAcgBkAAJGAFcAD1IA ZQBwAGwAeQAgAHQAbwAgAEYAbwBsAGQAZQByAAALAMCACCAGAAAAAADAAAAAAAAARgAAAACChQAA AQAAAAMAeoEIIAYAAAAAAMAAAAAAAABGAAAAANeFAAABAAAACwAfDgEAAAACAfgPAQAAABAAAAAR xZg2hcZARo+4P9nVeFfsAgH6DwEAAAAQAAAAt9qOsK56wkGEqBUf9LD7lQMA/g8FAAAAAgEJEAEA AAB2CQAAcgkAABcdAABMWkZ1zgnBGwMACgByY3BnMTI1gjIDQ2h0bWwxAzH4YmlkBAADMAEDAfcK gCcCpAPjAgBjaArAc2X4dDAgBxMCgBCDAFAEVr8IVQeyElUOUQMBEVcyBgD7BsMSVTMERhFZE2sS YwjvbQn3OxlPDjA1ElIMYGNnAFALCQFkMzYR4AulNHIgEIIqXA6yAZAOEDlkIDwOsiB4DtAAgDpI dj0iCHBuOgTwaGJlAMBzLW0N4ANgc2pvAYAtBaBtH9AO0CJdH3VvH/8hCSEwZg3gZXskJSHmdyJ/ I48lcAWwZA0h5m0lkA6wdHA6L6ovJfUuINcuIXEvJDRiLwHQMDQvDiAqcG0LIccol3cssC53My4B BbBnL1RSL1JFhEMtDrI0MCI+EmONHmczHgAfIGVhZC5NNDE2DvA8B4ABkCBuMmEHgD1HCfAEkGF0 rwWxBaACMAnwdCWQTSDmpCBXJ9EgMR4AKCRQNx6wBJAJgCAHgA9QdW0OKS4+HfAwwXN0eWxGZTUP MMEhLS0Koy/IKiBGAiEgRAEQC4CYaXRpAiAEICovCqPSQAISLWYA0GUKpAGRDQMwezoVINBseTpD eQdAaWIFEBpgOrcKsG4hIRBlLTE6FXAxNd4gPgAVcD5CHgAzPnIaYDp9OAZTNlI4zwrBcC4aTSEg TgWwAMBsLCD3PEBBag9QdkFoOqoAwC0wuQuAOjALgDyZRJQtBuDLAkAhgS4rADAxBTA8mcs6EwCQ eiSAMTFGwEcfhTumIjwlIiwicwBxS0ggBnIiPxZhOjxAbhprQgBzPUFBYkh5cD8EkExSQ9shIEgg NlItcM8FEAWwOSA8ADk5PJkYw+46CjI8mTJgeCFQBYMx4PE5QTp1bgSBTFFREUvWfnYEADkgCYBM n0xwOIBsvRjgdwmATc9O30/ucAhw/wtQUR9SL1M5V4A6m1bvV/0HXVhMUkpASFRNTCC+UBlQAhBB wQJANFFDEYG/S6FFXUT/Rg9Iz0glMEiv/0m6E3hLpwJAXJ9dr2bfZ+87S6dUk0UAwAMQP8MxN/9p r2qzNlBNUFkwBJAhIDFA+mwhYnA9cWu/Sf9LC0/9/wPwUuBV4FpSbftgUmCqYXL/b49qszFCYD9h T186aw9fD39gH3tSYbpsb2iOQWJ7oHD5QCFhdR6weM9wmFpgcfD9ACAtAiA78IDPc09LDznh3Qqw Z0AAM2IGYGM5Mhwj4zrmSDM4LjULgDOgSJH/Yv9isYyzM6COPj8WQwKKf/s69YoiOpBaPxY34Daf HwGXKRA2XzdoWwaQIGcyYEF+kiA5XT48H4E++QqjPG8l4BGATVABAYQi3QQgdoYBMpE0kXQh4FSQ mw9AAMB4JZBmYDI2IeDaL5fFL5eSN8BbCfAPUHxmXZNvlh+XL5g1C2B5XwhgBUCZOpfHmiJwmSxk /THgYZpxmtmfi57Am38uXK02Ai8vfx7QNRHgPAbgDGR5QhAAcGc9RU7sLVUF8ExSPQoymSCpo39Z RC5AHnMAIQMwqPJmYDPPPsCrJhHgHis5Nh8QQwH3MiALYAQQPZBaqwkAAKxv/R6jNi9BofCuREF3 r2+wcw5SDeARgTOQU2hvY9xrZajQiOAPQDqcnS9B/ZgwcJx+DkCj07bRqyYKov+rFwpyqzcKsbno rN0BwJShv7besZ+yr7sPth8eSTgeADgmbmJUkAKAqygnYf8BQL/ft4+4n7mvur+7z7zfj73vvv/I 78KEIzgyAdD9wys5FmDNj8JWNjA9QVSAuZTiPSdlz4F/aIYnzL/l0LNCoDFJIAPwVcBCEP2nQHZA ADkgWkCegBlQXGF/EbACMFrx18AEICEwBgBT/FAnBCDYISFxB4A4oQIg/1pAEYAFQA9QGVCQsDvw QgD+YgWQhCARsNfg2qJAAEBB9wdATCBxgXkAkAQgOSDZwf/ccdmB2rTXQxGA18HYITxAD9fBA/Da wNxTTUFSVLxJTtcgISAKQDkyLqzt/8WiVJKrCcb40P/PE5LQz4v+NOOfwN/Ez8Xfxu/H/+bv/8of yy/MP81P52/Bv8LPw9//6M/p3+rv6//tD+4f7y/wP+HxSVtCQV3kL/Rv9Xu+SZ4A3GEZUEwgAzJu tSHvFsBUACRwXFFvVABS8dkx79qiD2Fu0guAZ0IRlNBCAPvXIQhgbDOQPEC1ANgSCfDvWsAlsIoy 3GFt2BJUkKdA9mvYEgUzcRowlNDhIv///wEP9Yrx7/L/9u/3//kP+h//+y/8P/1P/l8Srw2/Cm8L f/8Xbw8fEC8RPxtvE18UbxV/+xaPF5BXQADa0DOQ2IIEAP80UTkwekDahANBikBS4DEglmSCYQXR VtsgdHXc0e5JMlF9gAgwSdcgZGEyAP0y8HdH0dUQGS/PL9A7kmD/BAR60ASEesAEwU1QkLHZES8q D+VP5l8vDjMrXDg1/zEY4VDW4jkgMb8rEW9gK2z+MjEY3XA9YNcArkCnQGlh595jJXLXwXll1wBV 0NvQ43tiA+4ocynYEtyg12H13GJzVdB04V0Yjxx/HY//Hp8fryC/Ic8i3yPvQl89b/8Zbxp/Rx8+ zz/fQO9B/0MP70QfRS9GP1AjSCmRtUB7gPvdYdrCPzGvSg9LH1afV6//WL9IL0wfTS9OP09PUF9R b/9Sf1OPRu9cf1k/Wk9bX13f/17vX/9hD2IfYy9kP2VPAk+/VbIncCz/38KOUXrgYbRg39lCBTTZ ILVAikF3tNAGdf/bsNwhKKEJgSYxjlEIgyfC/9rh3GIohik225Cq0a5g4DD/B4DYwZKAtLAIkAdw LdEDoLZko/DVEG3dQJ/gZgnv/2lfam9+v3/PDF9nb2tfbG//bX9uj2+fcK9xv3LPZi+En/9oT4Jf gI+F/4cPiB+JL4o/v4tPjF+Nb3P7oBEDVGYHsN+1YNgSePGuYbTgaToT38+cV0fbkDkhOuFiYanw /6jQ29DSQDigB7An0DxB2iD/oaKVMNlCBKHaYN2QqNA64f95kK8D4V2RX5Jvo/+lD6Yf/6cvqD+p T4/Pk7+Uz5Xflu//l/+ZD5ofmy+x/60Pqc+q3/+2v65vr3+wj7Gfsq+zv7TPL7Xfv8/Rr9K7MtOf IlRnJnHdcNUxIFLaIAOgIuQsIiXxaWbVb8Sft///uQ+6H8svvD3hf+KPz1i9L0++P79PwF/BbTEw zJEvjdsQdtLf1v9nNTi8odBib2R5rd43vKErkgXBYH3eYAAAAwANNP0/rQ4CAX8AAQAAAI0AAAAw MDAwMDAwMEI3REE4RUIwQUU3QUMyNDE4NEE4MTUxRkY0QjBGQjk1MDcwMDY0RTUxQUVDRDM1NDU0 NEVCNzhDQjc0MjFFMDAwOTBEMDAwMDAwMDFFMUU5MDAwMDFGMzYwOTM0Q0MyNTcxNEVBMjUyMjkw MDgzQkFDQzhFMDAwMDIzNDI2OUEzMDAwMAAAAAADAAYQSdleHgMABxCFAgAAAwAQEAAAAAADABEQ AQAAAB4ACBABAAAAZQAAAFJJQ0hBUkRTSE9DS0VZU0FJRDoiQlVUSVdJTExMRUFWRUlUVE9SRVBS RVNFTlRBVElWRVNPRlNTUFNUT0NPTU1FTlRPTlRIQVRESVJFQ1RMWSxCRUNBVVNFSU5USEVGSU5B TEEAAAAA6vg= ------=_NextPart_000_0036_01CA9DF3.FFCB7CA0-- ------------=_1264476254-7657-1-- From bernard_aboba@hotmail.com Mon Jan 25 19:51:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E7B3A681F for ; Mon, 25 Jan 2010 19:51:55 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVDJWM7T7XQk for ; Mon, 25 Jan 2010 19:51:54 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1264477915-16976-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 262563A680F for ; Mon, 25 Jan 2010 19:51:54 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 19:52:02 -0800 Message-ID: From: "Bernard Aboba" To: Date: Mon, 25 Jan 2010 19:52:02 -0800 X-Mailer: Microsoft Outlook 14.0 Subject: Re: [martini] Help (the Reader's Digest Guide to MARTINI) X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 03:51:55 -0000 This is a multi-part message in MIME format... ------------=_1264477915-16976-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1264477915-16976-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 262563A680F for ; Mon, 25 Jan 2010 19:51:54 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 19:52:02 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: Re: Help (the Reader's Digest Guide to MARTINI) Date: Mon, 25 Jan 2010 19:52:02 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005A_01CA9DF7.DD795600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFwrHKUh0UzvYt6E/tRXA96DFdcWw== X-MS-TNEF-Correlator: 00000000B7DA8EB0AE7AC24184A8151FF4B0FB95070064E51AECD354544EB78CB7421E00090D00000001E1E900001F360934CC25714EA252290083BACC8E0000234269A40000 Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 03:52:02.0648 (UTC) FILETIME=[EB4D3D80:01CA9E3A] ------=_NextPart_000_005A_01CA9DF7.DD795600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Eric Burger said: "I am having trouble understanding what the issues are in the proposed draft. I am seeing a lot of list traffic about "this is broken" and "that is broken." However, I do not get what "this" or "that" is. Can anyone help me on this? " [BA] At MARTINI Virtual Interim I, there was considerable discussion of the Problem Statement document (http://tools.ietf.org/html/draft-kaplan-martini-mixing-problems ), which details a number of issues encountered with current solutions. For slides and minutes, see: http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/ Since then, there has been discussion of solution requirements, with the most recent thread starting from the following message: http://www.ietf.org/mail-archive/web/martini/current/msg00253.html Also, there has been a discussion of how the potential solutions stack up against problems, including within the following thread: http://www.ietf.org/mail-archive/web/martini/current/msg00255.html Since we have set some time aside on the MARTINI Virtual Interim II agenda to discuss requirements, I am hoping we will be to get into these issues in more detail tomorrow. In terms of additional understanding of the problem, additional issues/concerns have also been brought up within some of the following messages: http://www.ietf.org/mail-archive/web/martini/current/msg00225.html http://www.ietf.org/mail-archive/web/martini/current/msg00227.html We have set some time aside on the agenda for invited talks, so I'm hoping we will be able to get into a more detailed discussion of these concerns as well. With respect to routing, there has been some discussion of use of DNS SRV RRs and their relation to being "authoritative" for a domain (and whether this is really germane to MARTINI or not): http://www.ietf.org/mail-archive/web/martini/current/msg00210.html ------=_NextPart_000_005A_01CA9DF7.DD795600 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgMDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBcEwAAKgAAAAsAAgABAAAAAwAmAAAAAAALACkAAAAAAB4A cAABAAAAMAAAAFJlOiBIZWxwICh0aGUgUmVhZGVyJ3MgRGlnZXN0IEd1aWRlIHRvIE1BUlRJTkkp AAIBcQABAAAAFgAAAAEBcKxylIdFM72LehP7UVwPegxXXFsAAAsAAQ4AAAAAAgEKDgEAAAAuAAAA AAAAAHF9eTxt27xBrgh5/rE5XfsBANlTnCJhprtFudq2LHCBs8EBACQA//8AAAAAAwAUDgEAAAAC ARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXAwAPNP0/rQ4eAAEwAQAAAA4AAABCZXJuYXJkIEFi b2JhAAAAHgADMAEAAAAaAAAAYmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbQAAAAsAFjABAAAAAwDe P59OAAADAPE/CQQAAB4A+j8BAAAADgAAAEJlcm5hcmQgQWJvYmEAAAADAAJZAAAWAAMACVkCAAAA CwAUaAAAAAACAeNlAQAAABUAAAAUtdWBhR0XhU25OyI/Us1TzgAANF8AAAACAeJlAQAAABQAAAC1 1YGFHReFTbk7Ij9SzVPOAAA0XwMAFIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAACwAggAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAHWACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAsApoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwCogAggBgAAAAAAwAAAAAAAAEYAAAAA DoUAAAAAAAADAKuACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIBsYAIIAYAAAAAAMAAAAAA AABGAAAAACCFAAABAAAAZAEAAAIBBAAAAAAAAAAFUmVwbHkISVBNLk5vdGUHTWVzc2FnZQJSRQUA AAAAAAAAAAEAAAAAAAAAAgAAAGYAAAACAAAAAQAAAAxSZXBseSB0byBBbGwISVBNLk5vdGUHTWVz c2FnZQJSRQUAAAAAAAAAAAEAAAAAAAAAAgAAAGcAAAADAAAAAgAAAAdGb3J3YXJkCElQTS5Ob3Rl B01lc3NhZ2UCRlcFAAAAAAAAAAABAAAAAAAAAAIAAABoAAAABAAAAAMAAAAPUmVwbHkgdG8gRm9s ZGVyCElQTS5Qb3N0BFBvc3QABQAAAAAAAAAAAQAAAAAAAAACAAAAbAAAAAgAAAAEAQVSAGUAcABs AHkAAlIARQAMUgBlAHAAbAB5ACAAdABvACAAQQBsAGwAAlIARQAHRgBvAHIAdwBhAHIAZAACRgBX AA9SAGUAcABsAHkAIAB0AG8AIABGAG8AbABkAGUAcgAACwDAgAggBgAAAAAAwAAAAAAAAEYAAAAA goUAAAEAAAADAHqBCCAGAAAAAADAAAAAAAAARgAAAADXhQAAAQAAAAsAHw4BAAAAAgH4DwEAAAAQ AAAAEcWYNoXGQEaPuD/Z1XhX7AIB+g8BAAAAEAAAALfajrCuesJBhKgVH/Sw+5UDAP4PBQAAAAIB CRABAAAAhg0AAIINAAAOLwAATFpGdfVZoAIDAAoAcmNwZzEyNYIyA0NodG1sMQMx+GJpZAQAAzAB AwH3CoAnAqQD4wIAY2gKwHNl+HQwIAcTAoAQgwBQBFa/CFUHshJVDlEDARFXMgYA+wbDElUzBEYR WRNrEmMI720J9zsZTw4wNRJSDGBjZwBQCwkBZDM2EeALpTRyIBCCKlwOsgGQDhA5ZCA8DrIgeA7Q AIA6SHY9IghwbjoE8GhiZQDAcy1tDeADYHNqbwGALQWgbR/QDtAiXR91bx//IQkhMGYN4GV7JCUh 5ncifyOPJXAFsGQNIeZtJZAOsHRwOi+qLyX1LiDXLiFxLyQ0Yi8B0DA0Lw4gKnBtCyHHKJd3LLAu dzMuAQWwZy9UUi9SRYRDLQ6yNDAiPhJjjR5nMx4AHyBlYWQuTTQxNg7wPAeAAZAgbjJhB4A9Rwnw BJBhdK8FsQWgAjAJ8HQlkE0g5qQgVyfRIDEeACgkUDcesASQCYAgB4APUHVtDikuPh3wMMFzdHls RmU1DzDBIS0tCqMvyCogRgIhIEQBEAuAmGl0aQIgBCAqLwqj0kACEi1mANBlCqQBkQ0DMHs6FSDQ bHk6Q3kHQGliBRAaYDq3CrBuISEQZS0xOhVwMTXeID4AFXA+Qh4AMz5yGmA6fTgGUzZSOM8KwXAu Gk0hIE4FsADAbCwg9zxAQWoPUHZBaDqqAMAtMLkLgDowC4A8mUSULQbgywJAIYEuKwAwMQUwPJnL OhMAkHokgDExRsBHH4U7piI8JSIsInMAcUtIIAZyIj8WYTo8QG4aa0IAcz1BQWJIeXA/BJBMUkPb ISBIIDZSLXDPBRAFsDkgPAA5OTyZGMPuOgoyPJkyYHghUAWDMeDxOUE6dW4EgUxRURFL1n52BAA5 IAmATJ9McDiAbL0Y4HcJgE3PTt9P7nAIcP8LUFEfUi9TOVeAOptW71f9B11YTFJKQEhUTUwgvlAZ UAIQQcECQDRRQxGBv0uhRV1E/0YPSM9IJTBIr/9JuhN4S6cCQFyfXa9m32fvO0unVJNFAMADED/D MTf/aa9qszZQTVBZMASQISAxQPpsIWJwPXFrv0n/SwtP/f8D8FLgVeBaUm37YFJgqmFy/2+ParMx QmA/YU9fOmsPXw9/YB97UmG6bG9ojkFie6Bw+UAhYXUesHjPcJhaYHHw/QAgLQIgO/CAz3NPSw85 4d0KsGdAADNiBmBjOTIcI+M65kgzOC41C4AzoEiR/2L/YrGMszOgjj4/FkMCin/7OvWKIjqQWj8W N+A2nx8BlykQNl83aFsGkCBnMmBBfpIgOV0+PB+BPvkKozxvJeARgE1QAQGEIt0EIHaGATKRNJF0 IeBUkJsPQADAeCWQZmAyNiHg2i+XxS+XkjfAWwnwD1B8Zl2Tb5Yfly+YNQtgeV8IYAVAmTqXx5oi cJksZP0x4GGacZrZn4uewJt/LlytNgIvL38e0DUR4DwG4AxkeUIQAHBnPUVO7C1VBfBMUj0KMpkg qaN/WUQuQB5zACEDMKjyZmAzzz7AqyYR4B4rOTYfEEMB9zIgC2AEED2QWqsJAACsb/0eozYvQaHw rkRBd69vsHPiRQUQYyBCCHCKQG5RuQtwZDqcnS9BmDBwnH7/DkCj07aRqyYKoqsXCnKrN/8Ksbmo rN0BwJShtp6xn7KvF7rPtd8eSTgeACZuYudUkAKAqygnYQFAv5+3T/+4X7lvun+7j7yfva++v8iv scJEIzgyAdDC6zkWYD/NT8IWNjA9QVSAlOI9J7dlz4F/aIYnzH/Qc0lMIHxtIBGAVACpEFpAA2B1 fwJgQABbU5TQAHAPUNcxd+sRgAVAdCYQIAQBClAEIN8KwNkxA6DZEn1Ab3HyM5DeZDHQKhHWlBGw ZdciMSD/GOAFQCEwQhGU0NdR2yAkUc9MIAbgoDHN33F1ZEDC6T4i0CjZEA9hD2E8YG9r/wnw3f/f D9A3TCBS4N3v4o934ArY4eD3LuSP5Z/jqEj9VeF2BJBCANagdkAxMNxh/4pABUDYw+gv6T/gG+yf 7a//46gFse+P8J/mq/J/84/jqP8EANtQPCADoABwoBAxsNbgv5/gofAHgNyA2hIEAD+s7f/FYlSS qwnGuPJvztOS0M9L/jT8T8CfxI/Fn8avx7//n//J38rvy//NDwAfwX/Cj8Of/wF/Ao8DnwSvBb8G zwffCO+BCflbQkFdIEHr4EBNQVJUSU7WoFb6aRDAdUOw1pAyUX2A1tDuSUIA2RHZ0XcmQDIiVCDf UvHdkD/xopAl8HUWMDlB99yC2RJ60G/XodbQP8Ax4N8mIDJx64EcIB3jKNDPMSD+aHrhKJcx8FWw KYBogBDQyy0TLdIv2wMta5hwq8HfJmA6wDkwORAmYXjXIX0xvR0zcy4xFxkncJ/gZJyyDmYlYI5Q lNB7SFlQ6EVSTBkQS9/gIG8hf/MijyObfX0lESVgcVCEQfxjZpEAhDCsSSb/KA8pH78jmvuvrMEw v6zPD+JhpfDcIClCANjAtGBootAtoO9u4dmh67AeYGK00dyR2VX/pXBawFtQGfF7cXYQ2RBQcP9Z UHrgHgFxYFDwQIPbUAwf/w0vDjpVoG5RUyAbcNmh5FG3h+A1wJ4wc1Rx29A6OQ9jH97dkWJhLtsA SEB6TZUAaHIAL3FnLnHBL9kY1S9KLxEZ1S8kXyVv/yZ9P89A30HqKv8sD0WPRp//Qcsx/zHPMt8z 6AqvC78Pr/8QvxHPEt8T7xT/Fg8XHw7P/1JPOZ86r1v/U69Uv1XPX/+/V+9Y/1oPWx8dgI5QYxzw /dkRbhpm9TDhAdvQ+IAb/P04ZiB64PZwGWAd0z1BN5P92RJtS6Fs8WoQHgHZEHrg76dQ0hEvU9wQ ZtqA1tDZEv17AGzcUHYR3BD5YGfAkeL/XD9dT2E/Yk9jX2RvZX9mj89nn2iv/L8+ry93frAtiLt7 IDVgLYSANPCuEGV+oGxlYn9xL2MvN+V/cHPEZzCaoDUzLvbiQp//Q68mfX6/f8+A34HnSI9Jn/+F X4Zvh3+ByE7fTq98X1DP/3Jfc290f3WPdp+Rb3i/ec//et9775M/XY9en1+vlJ+Vr3+Wv5fPmN+Z 75r/nA+dGUG9LWBvao8+0Bv8S5B32iQ769AegWkZoThnb5Jja//X0KkAnnA1UIQR2mIkAz1Q/2nx OIDYdDeh2gVwyG80cd//ns+iv6PPpN+l76b/qA+pH3+qL7lffY+LX4xvjX+BwjX/gh+DL4Q/wD/B T8Jfw2qJP/+KT8cPyB/JL8N4kG+QP74P/5JftA+1H7Yvtz+4T9Mfum//u3+8j72f1O+fH6AvoT/W T//XX9hv2X/aj9uf3K/dv2k//87ArCHOkD1hOEL5YTig+WH/6vAbYfmEHPAY3xnm8BBxof88sD7Q LTAb5mz98UEaMEuQ/nCxkxrBNWAZsDXw8cJxsP8eoGnw8dFuMT1wNlayEW5w/xqxNSTxwfaRHSDN QN9v4H//5G/lf+aP55/or+m/6s/r3//9v/jP4V/ibwJ/+i/7P/xP/wZ//m//fwCPAZ8CoBnQbiD/ G4AkMGwyb3CxgDiiGaE3EP8bcW+hPLBv8hylI9U9UBE57zZkjcBsEGoQcq9R7bMO8MsOkKxkYh0g dWcFsK/S77HV7kMcpXDPc7OPA88Hv/8IzwnfCu8L/w0PDh8PLx8//78/zQ/OH88vgcEbsMPPxN// xe8mHycvKD8pSsrvy/8s7/8t/y8PKVjSH9HvI+/UDxnv/xr/HA8dHx4vOP8gTyFfIm+/I38kjyWf M280fzWLNymv/yq/K89HL0g/SU9KWjDPMd//Tf9PD1AfSmg3/zfPRP857/86/zwPPR8+Lz8/Wg9B X0Jv/0N/RI9b3wQfBS8GP10/Xk9/X19gb2F/Yo9jn2SvZblXr+2f7q/xZRhAcrEhdhcgbGVkEJBy kGvzMRXhScFn3yM4MjE3aStbEPduqPOf9KFhE2H0y0Zg9pn/d0Gs7PWUFOesQVWwGGD33/9nX2tP bF9tb25/b49wn3Gv/3K/hn+Bj2g/aU+LP4Lvg///hQ+GH4cviD+JT4pfc+IXIfPycY4wZWP1IPHR FnFWIT5nq78Xg6zsrSAXs0ROglPtEFJWIFJSgBH/8ZCt8vLA8nGXAK8i8cKscKcYoo0PeTEyMHmM M5PY/mGvEK3A8PCMMFYgVYCf7/Wg8jF5jDST2HajrMF04OmwMSAoniJ39aCr0q3xz/Xw9eHycZfA bHn08Zehrm70s++2dsFurlApGW//jJ+Qj5Gfkq+Tv5TPld+W73+X/7CvRi9T/1UPVh/DcTH+MEq/ S89M37ePuJ+5r7q6/1HfUu++X79vwH+6yFkPWN//tV9a/6tfrG+tf66Pr5/Kb/+xv7LPs9+078w/ jO+N/48P/82fzq/Pv9DP0d/S79P/1Q+f1h+2GdlgElB0gHR5E3AsPScYQC+wLX7AemUAOjEyLjBw dDsN5kNm84DFYHk6IlRjdTGbUE5ld53QpxFuGCIsInSQ8PBmIif/4x/kL9eP2J/Zr+q/28vKr/4v 5YK7eci/3P/eD+7f4C/X61e68OwBL7zwdvJP9m8IZzU4y5Fib2R5XcveN8uR7gLg0H390AAAAwAN NP0/rQ4CAX8AAQAAAI0AAAAwMDAwMDAwMEI3REE4RUIwQUU3QUMyNDE4NEE4MTUxRkY0QjBGQjk1 MDcwMDY0RTUxQUVDRDM1NDU0NEVCNzhDQjc0MjFFMDAwOTBEMDAwMDAwMDFFMUU5MDAwMDFGMzYw OTM0Q0MyNTcxNEVBMjUyMjkwMDgzQkFDQzhFMDAwMDIzNDI2OUE0MDAwMAAAAAADAAYQQvBwtQMA BxAcBgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEVSSUNCVVJHRVJTQUlEOiJJQU1IQVZJ TkdUUk9VQkxFVU5ERVJTVEFORElOR1dIQVRUSEVJU1NVRVNBUkVJTlRIRVBST1BPU0VERFJBRlRJ QU1TRUVJTkdBTE9UT0ZMSVNUVFIAAAAAUg0= ------=_NextPart_000_005A_01CA9DF7.DD795600-- ------------=_1264477915-16976-1-- From bernard_aboba@hotmail.com Mon Jan 25 20:12:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557B43A67A3 for ; Mon, 25 Jan 2010 20:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_05=-1.11, 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 qEU96SiRfLjX for ; Mon, 25 Jan 2010 20:12:06 -0800 (PST) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 187573A676A for ; Mon, 25 Jan 2010 20:12:06 -0800 (PST) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 20:12:14 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 25 Jan 2010 20:12:14 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CA9DFA.AFC86090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYoo4MFRGESYFMuj6DV5Vt9DC92w== Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 04:12:14.0644 (UTC) FILETIME=[BDB52740:01CA9E3D] Subject: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 04:12:09 -0000 ------=_NextPart_000_0024_01CA9DFA.AFC86090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Given the complexities of some of the issues we've been talking about on the list, the chances for a productive discussion will probably be significantly be enhanced by use of slides during MARTINI Virtual Interim II tomorrow. So if you are on the agenda for MARTINI Virtual Interim II, please get your slides in to me and/or Spencer ASAP. I will be up early tomorrow so as to be able to get any received slides up on the archive prior to the meeting.. but I'd prefer not to have to scramble to get everything uploaded just before the meeting (or during or after it). Thanks in advance! ------=_NextPart_000_0024_01CA9DFA.AFC86090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given the = complexities of some of the issues we’ve been talking about on the = list, the chances for a productive discussion will probably be = significantly be enhanced by use of slides during MARTINI Virtual = Interim II tomorrow.

 

So if you = are on the agenda for MARTINI Virtual Interim II,  please get your = slides in to me and/or Spencer ASAP.   

 

I will be up = early tomorrow so as to be able to get any received slides up on the = archive prior to the meeting…. but I’d prefer not to have to = scramble to get everything uploaded just before the meeting (or during = or after it).

 

Thanks in = advance!

 

------=_NextPart_000_0024_01CA9DFA.AFC86090-- From john.elwell@siemens-enterprise.com Mon Jan 25 23:18:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BFE3A6855 for ; Mon, 25 Jan 2010 23:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaL0NNBYUsCa for ; Mon, 25 Jan 2010 23:18:15 -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 68FC93A6810 for ; Mon, 25 Jan 2010 23:18:14 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-663554; Tue, 26 Jan 2010 08:18:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 20F5F1EB82B0; Tue, 26 Jan 2010 08:18:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 26 Jan 2010 08:18:21 +0100 From: "Elwell, John" To: Paul Kyzivat Date: Tue, 26 Jan 2010 08:18:19 +0100 Thread-Topic: [martini] Requirements - rev2 Thread-Index: Acqd5kHdOoR08rmxQdGkMHGH/36pvgAb+gDg Message-ID: References: <4B5DD8D3.5050705@cisco.com> In-Reply-To: <4B5DD8D3.5050705@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: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:18:17 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 25 January 2010 17:46 > To: Elwell, John > Cc: Spencer Dawkins; martini@ietf.org > Subject: Re: [martini] Requirements - rev2 >=20 >=20 >=20 > Elwell, John wrote: >=20 > >> I apologize if I'm connecting the wrong dots, but when I=20 > >> joined Nortel in=20 > >> 1981, the largest PBXes they made topped out at 5000 lines. I=20 > >> wouldn't think=20 > >> of 5000 AORs as a small or medium PBX. > > [JRE] I tend to agree, that scalability to perhaps a few=20 > 100 AORs should be sufficient, but I seem to remember=20 > suggestions that it should be scalable to even bigger=20 > deployments. Any other views? >=20 > Is there an implicit assumption here that however many of these there=20 > are, it must be possible to encode a list of them in a message that=20 > doesn't exceed PDU size? >=20 > The wildcard proposals certainly attempt to compress the=20 > encoding, but=20 > in general those only work if the majority of the AORs have=20 > some textual=20 > commonalities that can be exploited. But while that is the=20 > norm, there=20 > are no guarantees that a pbx might not have 100 distinct=20 > phone numbers=20 > that have no patterned relationship that can be exploited via regular=20 > expressions to encode the full set concisely. [JRE] I would turn it around, and say that if we have a requirement for a l= arge value of N, it would preclude a solution where the AORs have to be enu= merated within a SIP message (assuming we want it to work over UDP, which p= erhaps should be an additional requirement, which I will post separately). = Grouping into ranges might help in some cases, but it is difficult to rely = on ranges to achieve a significant improvement in scalability. I tend to ag= ree with the notion that registration mode would be applied to smaller PBXs= , and that anything above a few hundred AORs would typically be solved usin= g static mode. But I also agree that is unwise to build in an arbitrary lim= it unless we can be sure that practical deployments would stay well below t= hat limit. So a solution with a limit of about 1000 AORs might be acceptabl= e if we don't anticipate deployments exceeding about 100-200 AORs, but woul= d be unwise if we can already envisage deployments of 500 AORs, say. I woul= d like to hear opinions on what a likely practical limit would be. John John >=20 > Thanks, > Paul > = From john.elwell@siemens-enterprise.com Mon Jan 25 23:22:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8427F3A68DD for ; Mon, 25 Jan 2010 23:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 7mLeEL9aHxg3 for ; Mon, 25 Jan 2010 23:22:34 -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 B709E3A6818 for ; Mon, 25 Jan 2010 23:22:33 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-663386; Tue, 26 Jan 2010 08:22:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 1EB5F1EB82AB; Tue, 26 Jan 2010 08:22:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 26 Jan 2010 08:22:41 +0100 From: "Elwell, John" To: Adam Roach , Paul Kyzivat Date: Tue, 26 Jan 2010 08:22:40 +0100 Thread-Topic: [martini] Requirements - rev2 Thread-Index: Acqd+cQ5Np77Lt85Rta5qIdxwrdzzwAXmQfw Message-ID: References: <4B5DD8D3.5050705@cisco.com> <4B5DF966.1040408@nostrum.com> In-Reply-To: <4B5DF966.1040408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:22:36 -0000 It tends not to be the case in Europe, but I have heard stories that the NA= numbering plan is getting pretty fragmented. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 25 January 2010 20:05 > To: Paul Kyzivat > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev2 >=20 > On 1/25/10 11:45 AM, Paul Kyzivat wrote: > > The wildcard proposals certainly attempt to compress the=20 > encoding, but=20 > > in general those only work if the majority of the AORs have some=20 > > textual commonalities that can be exploited. But while that is the=20 > > norm, there are no guarantees that a pbx might not have 100=20 > distinct=20 > > phone numbers that have no patterned relationship that can be=20 > > exploited via regular expressions to encode the full set concisely. >=20 > Is this really a requirement? It seems a bit of a tortured use case. >=20 > /a > = From john.elwell@siemens-enterprise.com Mon Jan 25 23:33:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06233A6810 for ; Mon, 25 Jan 2010 23:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 yij2BqfYc94u for ; Mon, 25 Jan 2010 23:33:18 -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 C2C9B3A6808 for ; Mon, 25 Jan 2010 23:33:17 -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-663355 for martini@ietf.org; Tue, 26 Jan 2010 08:18:26 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 206FE23F0278 for ; Tue, 26 Jan 2010 08:18:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jan 2010 08:18:26 +0100 From: "Elwell, John" To: "martini@ietf.org" Date: Tue, 26 Jan 2010 08:18:24 +0100 Thread-Topic: Transport requirements Thread-Index: AcqeV7+eBwhu9XApQsWYxLfIANWWFw== 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: [martini] Transport requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:33:18 -0000 Do we need an additional requirement that the solution must work over any e= xisting transport specified for SIP, including UDP? =20 John From christer.holmberg@ericsson.com Mon Jan 25 23:39:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0103A6814 for ; Mon, 25 Jan 2010 23:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wu76e8KJRqsS for ; Mon, 25 Jan 2010 23:39:24 -0800 (PST) Received: from mailgw9.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 92F3E3A67E1 for ; Mon, 25 Jan 2010 23:39:23 -0800 (PST) X-AuditID: c1b4fb24-b7bbdae00000494b-c0-4b5e9c3257a0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.ericsson.se (Symantec Mail Security) with SMTP id C8.6F.18763.23C9E5B4; Tue, 26 Jan 2010 08:39:30 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 26 Jan 2010 08:39:30 +0100 From: Christer Holmberg To: "Elwell, John" , "martini@ietf.org" Date: Tue, 26 Jan 2010 08:39:29 +0100 Thread-Topic: Transport requirements Thread-Index: AcqeV7+eBwhu9XApQsWYxLfIANWWFwAAorUQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] Transport requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:39:25 -0000 Do we have such requirement on "normal" registrations - or any other SIP tr= ansaction? Regards, Christer > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 26. tammikuuta 2010 9:18 > To: martini@ietf.org > Subject: [martini] Transport requirements >=20 > Do we need an additional requirement that the solution must=20 > work over any existing transport specified for SIP, including UDP? > =20 > John > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From sanjsinh@cisco.com Tue Jan 26 00:02:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665133A6814 for ; Tue, 26 Jan 2010 00:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbpoZEBnoIsL for ; Tue, 26 Jan 2010 00:02:01 -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 4B50C3A6808 for ; Tue, 26 Jan 2010 00:02:01 -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: ApoEANIwXktAZnwN/2dsb2JhbADBc5cIhDkE X-IronPort-AV: E=Sophos;i="4.49,345,1262563200"; d="scan'208";a="82008149" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2010 08:02:09 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.190]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o0Q828hx025443; Tue, 26 Jan 2010 08:02:09 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 02:02:09 -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: Tue, 26 Jan 2010 02:02:06 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CAA06899@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Transport requirements Thread-Index: AcqeV7+eBwhu9XApQsWYxLfIANWWFwAAorUQAADWDbA= References: From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Elwell, John" , X-OriginalArrivalTime: 26 Jan 2010 08:02:09.0640 (UTC) FILETIME=[DC2A7E80:01CA9E5D] Subject: Re: [martini] Transport requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:02:02 -0000 Considering registration may be the long pole, if a transport requirement works for register, it should work for other SIP transactions also. Sanjay > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Tuesday, January 26, 2010 1:09 PM > To: Elwell, John; martini@ietf.org > Subject: Re: [martini] Transport requirements >=20 >=20 > Do we have such requirement on "normal" registrations - or any other SIP transaction? >=20 > Regards, >=20 > Christer >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: 26. tammikuuta 2010 9:18 > > To: martini@ietf.org > > Subject: [martini] Transport requirements > > > > Do we need an additional requirement that the solution must > > work over any existing transport specified for SIP, including UDP? > > > > John > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Tue Jan 26 00:15:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6063A6895 for ; Tue, 26 Jan 2010 00:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 egr0LQSzQUp4 for ; Tue, 26 Jan 2010 00:15:55 -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 751783A67F8 for ; Tue, 26 Jan 2010 00:15:55 -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-663939; Tue, 26 Jan 2010 09:16:03 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6BD481EB82AB; Tue, 26 Jan 2010 09:16:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jan 2010 09:16:03 +0100 From: "Elwell, John" To: Adam Roach Date: Tue, 26 Jan 2010 09:16:01 +0100 Thread-Topic: Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/g Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> In-Reply-To: <4B5DE61F.70302@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:15:56 -0000 Changing the thread name to focus on another issue. We seem to have converged on what Adam calls contact routing, which basical= ly says that the domain part of the Request-URI in an inbound request shoul= d contain the domain part of the registered contact URI, leaving the user p= art to identify the particular AOR. I think this does indeed correspond to = one of the practices seen in the wild at present. This then leaves the question of whether we need to enumerate the different= user parts (and hence the AORs and their respective contacts), either in t= he request (PBX to SP) or in the response (SP to PBX). My question is wheth= er we need this at all - the question whether it should be in the request o= r the response can be addressed after we have determined whether it is need= ed at all. The argument for exchanging this information is to ensure that the two side= s are aligned, or at least to detect if there is misalignment. It is probab= ly not a mechanism for making changes to the set of user parts - my opinion= is that that is a provisioning issue and outside the scope of MARTINI. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 25 January 2010 18:43 > To: Elwell, John > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > =20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> > >> Seriously, go back and look at Adam's arguments very carefully. He > >> might wear excessively colorful trousers from time to time, but I > >> think most of his arguments are spot-on. Please everybody: go read > >> draft-roach-martini-up-00 and pay very careful attention=20 > to Section 9. > >> =20 > > [JRE] I just read it again, and to be honest most of what=20 > it claims could also apply to a well-chosen REGISTER-based mechanism. > > =20 >=20 > I agree, with emphasis on the terms "most" and "well-chosen." >=20 > I would not be entirely opposed to exploring what would constitute=20 > "well-chosen," and then figuring out how to solve the=20 > problems that fall=20 > outside the envelope covered by your term "most." >=20 > Based on your analysis post, your definition of "well-chosen"=20 > inherently=20 > includes some programmatic mapping from AORs to Contacts=20 > ("one contact=20 > URI per AOR," implying contact routing, not domain routing). I think=20 > that's a good place to start working from. >=20 > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > While it does=20 > solve a very real class of problems, that one relatively=20 > minor aspect of=20 > the draft is not the most mechanism it proposes. The majority of the=20 > problems it solves involve the explicit signaling of AORs in the=20 > request, the definition of a mechanism that enables "one=20 > contact URI per=20 > AOR," and the congruence with previous uses of REGISTER by employing=20 > "contact routing" instead of "domain routing." >=20 > /a > = From bruno.chatras@orange-ftgroup.com Tue Jan 26 00:29:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E1B3A68F8 for ; Tue, 26 Jan 2010 00:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 AId1v0TKyhGO for ; Tue, 26 Jan 2010 00:29:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id A5A153A67F6 for ; Tue, 26 Jan 2010 00:29:06 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 64CE11341E1; Tue, 26 Jan 2010 09:29:14 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2C75A23805E; Tue, 26 Jan 2010 09:29:14 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 09:29: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, 26 Jan 2010 09:29:13 +0100 Message-ID: <14989_1264494554_4B5EA7DA_14989_3446_1_9ECCF01B52E7AB408A7EB853526421410101AC52@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev1 Thread-Index: Acqd0CBe6DVNJXvPRJCrtQld7NaBYAAEi7wgAB/CJtA= References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B59DD3F.5030509@nostrum.com><4B5DAD72.4050806@cisco.com> <4B5DB3AE.40107@nostrum.com> From: To: , , X-OriginalArrivalTime: 26 Jan 2010 08:29:14.0498 (UTC) FILETIME=[A4A82620:01CA9E61] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.54222 Cc: HKaplan@acmepacket.com, martini@ietf.org Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:29:07 -0000 It sounds like a trick rather than a solid solution... > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : lundi 25 janvier 2010 18:19 > =C0 : Adam Roach; Paul Kyzivat > Cc : martini@ietf.org; Hadriel Kaplan > Objet : Re: [martini] Requirements - rev1 >=20 > For the two domain case, using a REGISTER-based approach, I=20 > would expect the PBX to behave as two PBXs and register twice.=20 >=20 > John >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 25 January 2010 15:07 > > To: Paul Kyzivat > > Cc: Elwell, John; Dean Willis; Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] Requirements - rev1 > >=20 > > On 1/25/10 8:40 AM, Paul Kyzivat wrote:=20 > >=20 > > inline...=20 > >=20=09 > > Elwell, John wrote:=20 > >=20=09 > >=20 > >=20 > > -----Original Message-----=20 > > From: Adam Roach > > [mailto:adam@nostrum.com] Sent: 22 January 2010 17:16 > >=20=09=09=09 > >=20 > >=20 > > This is great! Now we're using REGISTER=20 > to put an AOR to Contact=20 > > mapping in place (like it always > > has) instead of using it to install rules to override normal > > RFC3263 handling. Best of all, we're not saying "ignore DNS and use=20 > > this alternate mechanism for turning names into addresses" like we=20 > > have to with the "domain routing" approach. > >=20=09=09=09 > >=20 > > [JRE] This would seem reasonable. The point is,=20 > > if the PBX registers as its contact address pbx123@10.15.2.4,=20 > > then inbound INVITE requests would not contain that same=20 > > value in the Request-URI, but would contain something like=20 > > dsmith@10.15.2.4. The identity of the target is retained. So=20 > > I think we are in agreement.=20 > >=20=09=09 > >=20 > >=20 > > This could probably be made to work.=20 > >=20=09 > > But it requires new conventions about the form of contact URIs,=20 > > conventions we have never had before.=20 > >=20=09 > > The rule has always been that the registering device=20 > > can use whatever contact URI it wishes, as long as it routes=20 > > to itself, and in particular it can use the user-info portion=20 > > of that URI to encode arbitrary information that may be=20 > > helpful to itself.=20 > >=20=09 > > If an special convention is required for this new=20 > > mechanism, then we need to be very explicit about it.=20 > >=20=09 > >=20 > >=20 > > I'd like to be explicit about it at a protocol level. > >=20 > > I'll reiterate that the AOR to Contact mapping model I=20 > > propose in draft-roach-martini-up is *not* specific to the=20 > > use of PUBLISH. Using a similar mechanism in REGISTER --=20 > > whether in the header or in the body -- would achieve the=20 > > same goals. More importantly, it would address Dean's concern: > >=20 > >=20 > >=20 > > What happens when the PBX supports two domains, and=20 > > there might be user-name overlaps between the domains? If=20 > > both dwillis@eng.pan-am.com and dwillis@mktg.pan-am.com are=20 > > contact-routed by the SSP into dwillis@10.1.2.3, we have=20 > > something of a mess. > >=20 > >=20 > > Because, in this case, the registration could look something=20 > > like this (using the syntax from martini-up): > >=20 > >=20 > >=20 > > 1 full > > /sip:(.*)@eng.pan-am.com/sip:\1-eng@10.2.14.7/ > > /sip:(.*)@mktg.pan-am.com/sip:\1-mktg@10.2.14.7/ > >=20=09 > >=20 > >=20 > > That's very explicit. It's not even a convention; it's a protocol. > >=20 > > /a > >=20 > >=20 > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Tue Jan 26 00:29:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144D53A68F8 for ; Tue, 26 Jan 2010 00:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 1MeOfpmn7pHh for ; Tue, 26 Jan 2010 00:29:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id B0A493A67F6 for ; Tue, 26 Jan 2010 00:29:16 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 20C02374314; Tue, 26 Jan 2010 09:29:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id DA50538407A; Tue, 26 Jan 2010 09:29:24 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 09:29:24 +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, 26 Jan 2010 09:29:23 +0100 Message-ID: <20708_1264494564_4B5EA7E4_20708_85575_1_9ECCF01B52E7AB408A7EB853526421410101AC53@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAAHnsIA= References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> From: To: , X-OriginalArrivalTime: 26 Jan 2010 08:29:24.0936 (UTC) FILETIME=[AAE0DC80:01CA9E61] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.75128 Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 08:29:18 -0000 =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > Envoy=E9 : mardi 26 janvier 2010 09:16 > =C0 : Adam Roach > Cc : martini@ietf.org > Objet : [martini] Enumerating AORs/contacts >=20 > Changing the thread name to focus on another issue. >=20 > We seem to have converged on what Adam calls contact routing,=20 > which basically says that the domain part of the Request-URI=20 > in an inbound request should contain the domain part of the=20 > registered contact URI, leaving the user part to identify the=20 > particular AOR. I think this does indeed correspond to one of=20 > the practices seen in the wild at present. =3D=3D>BC: Hum, I still think that both the user part and the domain part s= hould be left unmodified. What are the concrete benefits for the PBX if onl= y the user part is left unchanged?=20 >=20 > This then leaves the question of whether we need to enumerate=20 > the different user parts (and hence the AORs and their=20 > respective contacts), either in the request (PBX to SP) or in=20 > the response (SP to PBX). My question is whether we need this=20 > at all - the question whether it should be in the request or=20 > the response can be addressed after we have determined=20 > whether it is needed at all. =3D=3D>BC: I have no strong feeling as to whether we need it on the interfa= ce between the pBX and the SSP's edge proxy but I believe we do need it in = the response from the Registrar to the SSP's edge proxy. >=20 > The argument for exchanging this information is to ensure=20 > that the two sides are aligned, or at least to detect if=20 > there is misalignment. It is probably not a mechanism for=20 > making changes to the set of user parts - my opinion is that=20 > that is a provisioning issue and outside the scope of MARTINI. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 25 January 2010 18:43 > > To: Elwell, John > > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > > Subject: Re: [martini] Requirements - rev1 > >=20 > > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > > >=20=20=20=20 > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> > > >> Seriously, go back and look at Adam's arguments very=20 > carefully. He=20 > > >> might wear excessively colorful trousers from time to=20 > time, but I=20 > > >> think most of his arguments are spot-on. Please=20 > everybody: go read=20 > > >> draft-roach-martini-up-00 and pay very careful attention > > to Section 9. > > >>=20=20=20=20=20=20 > > > [JRE] I just read it again, and to be honest most of what > > it claims could also apply to a well-chosen REGISTER-based=20 > mechanism. > > >=20=20=20=20 > >=20 > > I agree, with emphasis on the terms "most" and "well-chosen." > >=20 > > I would not be entirely opposed to exploring what would constitute=20 > > "well-chosen," and then figuring out how to solve the problems that=20 > > fall outside the envelope covered by your term "most." > >=20 > > Based on your analysis post, your definition of "well-chosen"=20 > > inherently > > includes some programmatic mapping from AORs to Contacts=20 > ("one contact=20 > > URI per AOR," implying contact routing, not domain=20 > routing). I think=20 > > that's a good place to start working from. > >=20 > > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > > While it does > > solve a very real class of problems, that one relatively=20 > minor aspect=20 > > of the draft is not the most mechanism it proposes. The majority of=20 > > the problems it solves involve the explicit signaling of=20 > AORs in the=20 > > request, the definition of a mechanism that enables "one=20 > contact URI=20 > > per AOR," and the congruence with previous uses of REGISTER by=20 > > employing "contact routing" instead of "domain routing." > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Tue Jan 26 01:20:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216A13A68FB for ; Tue, 26 Jan 2010 01:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 HsqZNlKKfeVe for ; Tue, 26 Jan 2010 01:19:58 -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 65EB93A68F7 for ; Tue, 26 Jan 2010 01:19:58 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-664860; Tue, 26 Jan 2010 10:20:07 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 1CDD01EB82B0; Tue, 26 Jan 2010 10:20:07 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jan 2010 10:20:07 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "adam@nostrum.com" Date: Tue, 26 Jan 2010 10:20:05 +0100 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAAHnsIAAAcxW8A== Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> <20708_1264494564_4B5EA7E4_20708_85575_1_9ECCF01B52E7AB408A7EB853526421410101AC53@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20708_1264494564_4B5EA7E4_20708_85575_1_9ECCF01B52E7AB408A7EB853526421410101AC53@ftrdmel0.rd.francetelecom.fr> 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: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:20:00 -0000 =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 26 January 2010 08:29 > To: Elwell, John; adam@nostrum.com > Cc: martini@ietf.org > Subject: RE: [martini] Enumerating AORs/contacts >=20 > =20 >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org=20 > > [mailto:martini-bounces@ietf.org] De la part de Elwell, John > > Envoy=E9 : mardi 26 janvier 2010 09:16 > > =C0 : Adam Roach > > Cc : martini@ietf.org > > Objet : [martini] Enumerating AORs/contacts > >=20 > > Changing the thread name to focus on another issue. > >=20 > > We seem to have converged on what Adam calls contact routing,=20 > > which basically says that the domain part of the Request-URI=20 > > in an inbound request should contain the domain part of the=20 > > registered contact URI, leaving the user part to identify the=20 > > particular AOR. I think this does indeed correspond to one of=20 > > the practices seen in the wild at present. > =3D=3D>BC: Hum, I still think that both the user part and the=20 > domain part should be left unmodified. What are the concrete=20 > benefits for the PBX if only the user part is left unchanged?=20 [JRE] For reasons that Adam has given - sending a request to sip:+12345@sp.= com to pbx.com will result in looping back to sp.com, since pbx.com is not = responsible for that domain. > >=20 > > This then leaves the question of whether we need to enumerate=20 > > the different user parts (and hence the AORs and their=20 > > respective contacts), either in the request (PBX to SP) or in=20 > > the response (SP to PBX). My question is whether we need this=20 > > at all - the question whether it should be in the request or=20 > > the response can be addressed after we have determined=20 > > whether it is needed at all. > =3D=3D>BC: I have no strong feeling as to whether we need it on=20 > the interface between the pBX and the SSP's edge proxy but I=20 > believe we do need it in the response from the Registrar to=20 > the SSP's edge proxy. [JRE] Can we somehow capture a requirement on this? Just saying it needs to= be conveyed to the edge proxy is not sufficient. We need to identify a pro= blem and capture a requirement that avoids that problem. John >=20 > >=20 > > The argument for exchanging this information is to ensure=20 > > that the two sides are aligned, or at least to detect if=20 > > there is misalignment. It is probably not a mechanism for=20 > > making changes to the set of user parts - my opinion is that=20 > > that is a provisioning issue and outside the scope of MARTINI. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: Adam Roach [mailto:adam@nostrum.com] > > > Sent: 25 January 2010 18:43 > > > To: Elwell, John > > > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > > > Subject: Re: [martini] Requirements - rev1 > > >=20 > > > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > > > > > =20 > > > >> -----Original Message----- > > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > > >> > > > >> Seriously, go back and look at Adam's arguments very=20 > > carefully. He=20 > > > >> might wear excessively colorful trousers from time to=20 > > time, but I=20 > > > >> think most of his arguments are spot-on. Please=20 > > everybody: go read=20 > > > >> draft-roach-martini-up-00 and pay very careful attention > > > to Section 9. > > > >> =20 > > > > [JRE] I just read it again, and to be honest most of what > > > it claims could also apply to a well-chosen REGISTER-based=20 > > mechanism. > > > > =20 > > >=20 > > > I agree, with emphasis on the terms "most" and "well-chosen." > > >=20 > > > I would not be entirely opposed to exploring what would=20 > constitute=20 > > > "well-chosen," and then figuring out how to solve the=20 > problems that=20 > > > fall outside the envelope covered by your term "most." > > >=20 > > > Based on your analysis post, your definition of "well-chosen"=20 > > > inherently > > > includes some programmatic mapping from AORs to Contacts=20 > > ("one contact=20 > > > URI per AOR," implying contact routing, not domain=20 > > routing). I think=20 > > > that's a good place to start working from. > > >=20 > > > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > > > While it does > > > solve a very real class of problems, that one relatively=20 > > minor aspect=20 > > > of the draft is not the most mechanism it proposes. The=20 > majority of=20 > > > the problems it solves involve the explicit signaling of=20 > > AORs in the=20 > > > request, the definition of a mechanism that enables "one=20 > > contact URI=20 > > > per AOR," and the congruence with previous uses of REGISTER by=20 > > > employing "contact routing" instead of "domain routing." > > >=20 > > > /a > > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > = From bruno.chatras@orange-ftgroup.com Tue Jan 26 01:49:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA6F3A67E3 for ; Tue, 26 Jan 2010 01:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 KLs9emphky9Y for ; Tue, 26 Jan 2010 01:49:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 0222A3A6405 for ; Tue, 26 Jan 2010 01:49:57 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DE61B3241E4; Tue, 26 Jan 2010 10:50:04 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C3F7627C064; Tue, 26 Jan 2010 10:50:04 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 10:50:05 +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, 26 Jan 2010 10:50:03 +0100 Message-ID: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAAHnsIAAAcxW8AAA0Pzg References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> <20708_1264494564_4B5EA7E4_20708_85575_1_9ECCF01B52E7AB408A7EB853526421410101AC53@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 26 Jan 2010 09:50:05.0183 (UTC) FILETIME=[EFE3F0F0:01CA9E6C] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.13.111532 Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 09:49:59 -0000 =20 > -----Message d'origine----- > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Envoy=E9 : mardi 26 janvier 2010 10:20 > =C0 : CHATRAS Bruno RD-CORE-ISS; adam@nostrum.com > Cc : martini@ietf.org > Objet : RE: [martini] Enumerating AORs/contacts >=20 >=20=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > > [mailto:bruno.chatras@orange-ftgroup.com] > > Sent: 26 January 2010 08:29 > > To: Elwell, John; adam@nostrum.com > > Cc: martini@ietf.org > > Subject: RE: [martini] Enumerating AORs/contacts > >=20 > >=20=20 > >=20 > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Elwell,=20 > John Envoy=E9=20 > > > : mardi 26 janvier 2010 09:16 =C0 : Adam Roach Cc :=20 > martini@ietf.org=20 > > > Objet : [martini] Enumerating AORs/contacts > > >=20 > > > Changing the thread name to focus on another issue. > > >=20 > > > We seem to have converged on what Adam calls contact=20 > routing, which=20 > > > basically says that the domain part of the Request-URI in=20 > an inbound=20 > > > request should contain the domain part of the registered contact=20 > > > URI, leaving the user part to identify the particular=20 > AOR. I think=20 > > > this does indeed correspond to one of the practices seen=20 > in the wild=20 > > > at present. > > =3D=3D>BC: Hum, I still think that both the user part and the=20 > domain part=20 > > should be left unmodified. What are the concrete benefits=20 > for the PBX=20 > > if only the user part is left unchanged? > [JRE] For reasons that Adam has given - sending a request to=20 > sip:+12345@sp.com to pbx.com will result in looping back to=20 > sp.com, since pbx.com is not responsible for that domain. =3D=3D>BC: I was referring to a URI of the form user@enterprise.com, not us= er@sp.com >=20 > > >=20 > > > This then leaves the question of whether we need to enumerate=20 > > > the different user parts (and hence the AORs and their=20 > > > respective contacts), either in the request (PBX to SP) or in=20 > > > the response (SP to PBX). My question is whether we need this=20 > > > at all - the question whether it should be in the request or=20 > > > the response can be addressed after we have determined=20 > > > whether it is needed at all. > > =3D=3D>BC: I have no strong feeling as to whether we need it on=20 > > the interface between the pBX and the SSP's edge proxy but I=20 > > believe we do need it in the response from the Registrar to=20 > > the SSP's edge proxy. > [JRE] Can we somehow capture a requirement on this? Just=20 > saying it needs to be conveyed to the edge proxy is not=20 > sufficient. We need to identify a problem and capture a=20 > requirement that avoids that problem. =3D=3D>BC: The mechanism shall ensure that an SSP's edge proxy that is resp= onsible for asserting identities as per RFC 3325 is made aware of the list = of identities implictly registered in the registrar. >=20 > John >=20 >=20 >=20 > >=20 > > >=20 > > > The argument for exchanging this information is to ensure=20 > > > that the two sides are aligned, or at least to detect if=20 > > > there is misalignment. It is probably not a mechanism for=20 > > > making changes to the set of user parts - my opinion is that=20 > > > that is a provisioning issue and outside the scope of MARTINI. > > >=20 > > > John > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Adam Roach [mailto:adam@nostrum.com] > > > > Sent: 25 January 2010 18:43 > > > > To: Elwell, John > > > > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > > > > Subject: Re: [martini] Requirements - rev1 > > > >=20 > > > > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > > > > > > >=20=20=20=20 > > > > >> -----Original Message----- > > > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > > > >> > > > > >> Seriously, go back and look at Adam's arguments very=20 > > > carefully. He=20 > > > > >> might wear excessively colorful trousers from time to=20 > > > time, but I=20 > > > > >> think most of his arguments are spot-on. Please=20 > > > everybody: go read=20 > > > > >> draft-roach-martini-up-00 and pay very careful attention > > > > to Section 9. > > > > >>=20=20=20=20=20=20 > > > > > [JRE] I just read it again, and to be honest most of what > > > > it claims could also apply to a well-chosen REGISTER-based=20 > > > mechanism. > > > > >=20=20=20=20 > > > >=20 > > > > I agree, with emphasis on the terms "most" and "well-chosen." > > > >=20 > > > > I would not be entirely opposed to exploring what would=20 > > constitute=20 > > > > "well-chosen," and then figuring out how to solve the=20 > > problems that=20 > > > > fall outside the envelope covered by your term "most." > > > >=20 > > > > Based on your analysis post, your definition of "well-chosen"=20 > > > > inherently > > > > includes some programmatic mapping from AORs to Contacts=20 > > > ("one contact=20 > > > > URI per AOR," implying contact routing, not domain=20 > > > routing). I think=20 > > > > that's a good place to start working from. > > > >=20 > > > > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > > > > While it does > > > > solve a very real class of problems, that one relatively=20 > > > minor aspect=20 > > > > of the draft is not the most mechanism it proposes. The=20 > > majority of=20 > > > > the problems it solves involve the explicit signaling of=20 > > > AORs in the=20 > > > > request, the definition of a mechanism that enables "one=20 > > > contact URI=20 > > > > per AOR," and the congruence with previous uses of REGISTER by=20 > > > > employing "contact routing" instead of "domain routing." > > > >=20 > > > > /a > > > >=20 > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > >=20 > > ********************************* > > This message and any attachments (the "message") are=20 > > confidential and intended solely for the addressees.=20 > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration.=20 > > France Telecom Group shall not be liable for the message if=20 > > altered, changed or falsified. > > If you are not the intended addressee of this message, please=20 > > cancel it immediately and inform the sender. > > ******************************** > >=20 > >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From spencer@wonderhamster.org Tue Jan 26 05:47:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEF43A685A for ; Tue, 26 Jan 2010 05:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, STOX_REPLY_TYPE=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 aIqOC0oekPNN for ; Tue, 26 Jan 2010 05:47:01 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id CD6D93A6822 for ; Tue, 26 Jan 2010 05:47:00 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MDyyt-1NaYRt1wp5-00HVly; Tue, 26 Jan 2010 08:46:51 -0500 Message-ID: From: "Spencer Dawkins" To: , , References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> Date: Tue, 26 Jan 2010 07:46:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX18B+Exodv6XAejRjKnWAKS09+uIMTTqhb/sTt9 CPazPc9hL2QvQyX5NZ7pBp/gSAXTQvX+5TMxIf5YWaAKHXlmRa Tmi2b3xTVbe8MmO4dTDKk5pY/fr/LBVMAVbQI6JUS8= Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 13:47:01 -0000 Hi, Bruno, The problem with user@enterprise.com is that requests from outside the service provider to this AOR would go straight to the SIP-PBX without traversing any service provider proxy - unless we dork with two-faced DNS, etc. Or am I misunderstanding? Thanks, Spencer (as individual) ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, January 26, 2010 3:50 AM Subject: Re: [martini] Enumerating AORs/contacts > > ==>BC: Hum, I still think that both the user part and the > domain part > > should be left unmodified. What are the concrete benefits > for the PBX > > if only the user part is left unchanged? > [JRE] For reasons that Adam has given - sending a request to > sip:+12345@sp.com to pbx.com will result in looping back to > sp.com, since pbx.com is not responsible for that domain. ==>BC: I was referring to a URI of the form user@enterprise.com, not user@sp.com From pkyzivat@cisco.com Tue Jan 26 06:00:09 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1AC3A6975 for ; Tue, 26 Jan 2010 06:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrlfJa3VR7O4 for ; Tue, 26 Jan 2010 06:00:08 -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 437D23A6966 for ; Tue, 26 Jan 2010 06:00:08 -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: ApoEAPKDXktAZnwM/2dsb2JhbADBZJcMgi2CDAQ X-IronPort-AV: E=Sophos;i="4.49,346,1262563200"; d="scan'208";a="82062939" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2010 14:00:17 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.172]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0QE0GWj015016; Tue, 26 Jan 2010 14:00:16 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 08:00:16 -0600 Received: from [10.86.241.46] ([10.86.241.46]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 08:00:16 -0600 Message-ID: <4B5EF56E.7040908@cisco.com> Date: Tue, 26 Jan 2010 09:00:14 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2010 14:00:16.0196 (UTC) FILETIME=[E326C040:01CA9E8F] Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:00:09 -0000 Elwell, John wrote: > Changing the thread name to focus on another issue. > > We seem to have converged on what Adam calls contact routing, which basically says that the domain part of the Request-URI in an inbound request should contain the domain part of the registered contact URI, leaving the user part to identify the particular AOR. I think this does indeed correspond to one of the practices seen in the wild at present. > > This then leaves the question of whether we need to enumerate the different user parts (and hence the AORs and their respective contacts), either in the request (PBX to SP) or in the response (SP to PBX). My question is whether we need this at all - the question whether it should be in the request or the response can be addressed after we have determined whether it is needed at all. > > The argument for exchanging this information is to ensure that the two sides are aligned, or at least to detect if there is misalignment. It is probably not a mechanism for making changes to the set of user parts - my opinion is that that is a provisioning issue and outside the scope of MARTINI. AFAIK it has generally been the case that "I am the master of my URIs": that the URIs addressed specifically to my device are those that I have minted - that the whole URI, including the user part is my business. (If you want to talk to me, send a request to a URI that I provide, rather than making up something.) The registration model certainly has preserved that property, until now. This is important, because I may have only one domain/port combination under my control, and I may need to multiplex it using the user part. If you start "making up" URIs with my domain and port, there are no guarantees that you won't infringe on values I am using for something else. If we are going to change this model, it must be done very deliberately, and with clear bounds, so that I still have predictable sub-ranges I can control within the user part. This could be achieved by contract - my service agreement with the SSP specifies what values it might put into my contact URI. Or this could be achieved by my providing an algorithm to the SSP to use in mapping other addresses into my contact URI space. That is what Adam has proposed with his regular expression mechanism. Another way would be to leave the user part of the contact unchanged, and add a URI parameter. Thanks, Paul > John > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 25 January 2010 18:43 >> To: Elwell, John >> Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan >> Subject: Re: [martini] Requirements - rev1 >> >> On 1/25/10 10:13 AM, Elwell, John wrote: >>> >>>> -----Original Message----- >>>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>>> >>>> Seriously, go back and look at Adam's arguments very carefully. He >>>> might wear excessively colorful trousers from time to time, but I >>>> think most of his arguments are spot-on. Please everybody: go read >>>> draft-roach-martini-up-00 and pay very careful attention >> to Section 9. >>>> >>> [JRE] I just read it again, and to be honest most of what >> it claims could also apply to a well-chosen REGISTER-based mechanism. >>> >> I agree, with emphasis on the terms "most" and "well-chosen." >> >> I would not be entirely opposed to exploring what would constitute >> "well-chosen," and then figuring out how to solve the >> problems that fall >> outside the envelope covered by your term "most." >> >> Based on your analysis post, your definition of "well-chosen" >> inherently >> includes some programmatic mapping from AORs to Contacts >> ("one contact >> URI per AOR," implying contact routing, not domain routing). I think >> that's a good place to start working from. >> >> Don't get hung up on martini-up's proposal to use PUBLISH. >> While it does >> solve a very real class of problems, that one relatively >> minor aspect of >> the draft is not the most mechanism it proposes. The majority of the >> problems it solves involve the explicit signaling of AORs in the >> request, the definition of a mechanism that enables "one >> contact URI per >> AOR," and the congruence with previous uses of REGISTER by employing >> "contact routing" instead of "domain routing." >> >> /a >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From adam@nostrum.com Tue Jan 26 06:10:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAD13A6971 for ; Tue, 26 Jan 2010 06:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzesGc2MWCbA for ; Tue, 26 Jan 2010 06:10:23 -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 603813A696E for ; Tue, 26 Jan 2010 06:10:23 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QEAVSA015407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 08:10:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5EF7D7.3030305@nostrum.com> Date: Tue, 26 Jan 2010 08:10:31 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:10:25 -0000 On 1/26/10 02:16, Jan 26, Elwell, John wrote: > Changing the thread name to focus on another issue. > > We seem to have converged on what Adam calls contact routing, which basically says that the domain part of the Request-URI in an inbound request should contain the domain part of the registered contact URI, leaving the user part to identify the particular AOR. So, that's not *quite* right. The right-hand-side corresponds to the PBX. In the dynamic-IP scenario, it ends up being the PBX's IP address, not a domain it claims responsibility for. /a From BLINDSAY@nortel.com Tue Jan 26 06:42:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30D03A6873 for ; Tue, 26 Jan 2010 06:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=0.755, 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 ox8fQ-qTbz-Y for ; Tue, 26 Jan 2010 06:42:02 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 484993A6844 for ; Tue, 26 Jan 2010 06:42:02 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0QEfZI12006; Tue, 26 Jan 2010 14:41:36 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 09:41:23 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C3C88D0@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAA53tIA= References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> From: "Brian Lindsay" To: "Elwell, John" , "Adam Roach" Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:42:03 -0000 Hi John, I am not sure we have converged on this. There seemed to be a large measure of agreement in earlier threads that the domain portion reflect the domain name associated with the pbx. Which means that a re-targetting may need to occur, but not necessarily that a "contact routing" approach was being used. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Tuesday, January 26, 2010 3:16 AM To: Adam Roach Cc: martini@ietf.org Subject: [martini] Enumerating AORs/contacts Changing the thread name to focus on another issue. We seem to have converged on what Adam calls contact routing, which basically says that the domain part of the Request-URI in an inbound request should contain the domain part of the registered contact URI, leaving the user part to identify the particular AOR. I think this does indeed correspond to one of the practices seen in the wild at present. This then leaves the question of whether we need to enumerate the different user parts (and hence the AORs and their respective contacts), either in the request (PBX to SP) or in the response (SP to PBX). My question is whether we need this at all - the question whether it should be in the request or the response can be addressed after we have determined whether it is needed at all. The argument for exchanging this information is to ensure that the two sides are aligned, or at least to detect if there is misalignment. It is probably not a mechanism for making changes to the set of user parts - my opinion is that that is a provisioning issue and outside the scope of MARTINI. John > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 25 January 2010 18:43 > To: Elwell, John > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > Subject: Re: [martini] Requirements - rev1 >=20 > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > =20 > >> -----Original Message----- > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > >> > >> Seriously, go back and look at Adam's arguments very carefully. He=20 > >> might wear excessively colorful trousers from time to time, but I=20 > >> think most of his arguments are spot-on. Please everybody: go read=20 > >> draft-roach-martini-up-00 and pay very careful attention > to Section 9. > >> =20 > > [JRE] I just read it again, and to be honest most of what > it claims could also apply to a well-chosen REGISTER-based mechanism. > > =20 >=20 > I agree, with emphasis on the terms "most" and "well-chosen." >=20 > I would not be entirely opposed to exploring what would constitute=20 > "well-chosen," and then figuring out how to solve the problems that=20 > fall outside the envelope covered by your term "most." >=20 > Based on your analysis post, your definition of "well-chosen"=20 > inherently > includes some programmatic mapping from AORs to Contacts ("one contact > URI per AOR," implying contact routing, not domain routing). I think=20 > that's a good place to start working from. >=20 > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > While it does > solve a very real class of problems, that one relatively minor aspect=20 > of the draft is not the most mechanism it proposes. The majority of=20 > the problems it solves involve the explicit signaling of AORs in the=20 > request, the definition of a mechanism that enables "one contact URI=20 > per AOR," and the congruence with previous uses of REGISTER by=20 > employing "contact routing" instead of "domain routing." >=20 > /a >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Tue Jan 26 06:54:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF003A67B6 for ; Tue, 26 Jan 2010 06:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIm5hy1q1u+6 for ; Tue, 26 Jan 2010 06:54:04 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B375F3A67FA for ; Tue, 26 Jan 2010 06:54:03 -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; Tue, 26 Jan 2010 09:54:12 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 09:54:12 -0500 From: Hadriel Kaplan To: Bernard Aboba , "martini@ietf.org" Date: Tue, 26 Jan 2010 09:53:58 -0500 Thread-Topic: [martini] Request for Slides -- Take Two Thread-Index: AQIYoo4MFRGESYFMuj6DV5Vt9DC925EL5jLg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1A2Cmail_" MIME-Version: 1.0 Subject: Re: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 14:54:08 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1A2Cmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest we change the format of this meeting. Currently you have Adam an= d I scheduled to deliver presentations on our drafts, but nothing's changed= with them afaik. The email discussion so far has not really been specific= to the drafts - most of the topics have been applicable no matter which dr= aft model is used. So I suggest we just go through John's requirements and then discuss the em= ail topics, and skip the drafts. It appears the topics have been: 1) What to do with the req-uri: leave alone, contact-routing, or re-t= argeting. 2) Which entity "owns" or is responsible for the Enterprise domain. 3) Whether to encode the implicitly registered AoR's in the REGISTER/= PUBLISH transaction, or not. Oddly the one topic I thought would be the hot one from the last meeting, n= amely GRUU, has not been discussed on the mailing list afaict. -hadriel ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Bernard Aboba Sent: Monday, January 25, 2010 11:12 PM To: martini@ietf.org Subject: [martini] Request for Slides -- Take Two Given the complexities of some of the issues we've been talking about on th= e list, the chances for a productive discussion will probably be significan= tly be enhanced by use of slides during MARTINI Virtual Interim II tomorrow= . So if you are on the agenda for MARTINI Virtual Interim II, please get you= r slides in to me and/or Spencer ASAP. I will be up early tomorrow so as to be able to get any received slides up = on the archive prior to the meeting.... but I'd prefer not to have to scram= ble to get everything uploaded just before the meeting (or during or after = it). Thanks in advance! --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1A2Cmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suggest we change the format of this meeting.  Currently you have Adam and I scheduled to deliver presentat= ions on our drafts, but nothing’s changed with them afaik.  The email di= scussion so far has not really been specific to the drafts – most of the topics have = been applicable no matter which draft model is used.

So I suggest we just go through John&#= 8217;s requirements and then discuss the email topics, and skip the drafts.

 

It appears the topics have been:<= /o:p>

1)      = What to do with the req-uri: leave alone, contact-routing, or re-targeting.

2)      = Which entity “owns” or is responsible for the Enterprise domain.

3)      = Whether to encode the implicitly registered AoR’s in the REGISTER/PUBLISH transaction, or not.

 

Oddly the one topic I thought would be= the hot one from the last meeting, namely GRUU, has not been discussed on the mailing list afaict.

 

-hadriel

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, January 25, 20= 10 11:12 PM
To: martini@ietf.org
Subject: [martini] Request f= or Slides -- Take Two=

 

Given the complexities of some of the issues we’ve been talking about on th= e list, the chances for a productive discussion will probably be significantly be enhanced by use of slides during MARTINI Virtual Interim II tomorrow. =

 

So if you are on the agenda for MARTINI Virtual Interim II,  please get y= our slides in to me and/or Spencer ASAP.   <= /p>

 

I will be up early tomorrow so as to be able to get any received slides up on= the archive prior to the meeting…. but I’d prefer not to have to sc= ramble to get everything uploaded just before the meeting (or during or after it). <= /o:p>

 

Thanks in advance!

 

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1A2Cmail_-- From HKaplan@acmepacket.com Tue Jan 26 07:01:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026F03A68CC for ; Tue, 26 Jan 2010 07:01:38 -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 HlqnMhoJBpOq for ; Tue, 26 Jan 2010 07:01:37 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0EFE03A6803 for ; Tue, 26 Jan 2010 07:01:36 -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; Tue, 26 Jan 2010 10:01:46 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:01:46 -0500 From: Hadriel Kaplan To: "martini@ietf.org" Date: Tue, 26 Jan 2010 10:01:44 -0500 Thread-Topic: Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQ== 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: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:01:38 -0000 On the topic of listing implicitly registered AoR's (what has been done so = far in P-Associated-URI), the emails on this seem to focus on either requir= ing it, or not at all. But there was a third option proposed by someone on= the last virtual meeting call: use reg-event for that. In other words, don't put them in a PAU/whatever of the REGISTER (or PUBLIS= H) request or response. Instead, use the subscription for reg-event to lis= t them. In the P-CSCF/edge-proxy case, the edge-proxy itself can subscribe= to that package after the IP-PBX has registered itself. That seemed like a good compromise to me. (I preferred having it in the REG= ISTER response, but we can't have everything :) -hadriel From dean.willis@softarmor.com Tue Jan 26 07:05:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2353A6803 for ; Tue, 26 Jan 2010 07:05:32 -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 BWR84Ttrw8Jz for ; Tue, 26 Jan 2010 07:05:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A039E3A63EC for ; Tue, 26 Jan 2010 07:05:31 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QF5eSu016295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:05:41 -0600 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 09:05:34 -0600 References: X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:05:32 -0000 On Jan 25, 2010, at 11:35 AM, Elwell, John wrote: > Spencer, > > My feedback below. > >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] >> Sent: 25 January 2010 16:42 >> To: Elwell, John; martini@ietf.org >> Subject: Re: [martini] Requirements - rev2 >> >> Hi, John, >> >> (As co-chair) Thanks for continuing to herd this along the path. >> >> (as individual) A couple of questions inline... >> >> >>> - The mechanism MUST allow the PBX to be responsible for >> its AORs and to >>> handle requests to those AORs according to its rules. >> >> Are we crystal clear on what "responsible for its AORs" means? I am >> remembering conversations that centered around where DNS >> records pointed, >> for instance. > [JRE] Yes, I agree we need something more concrete. Any text > proposals from anyone? How about: Such that the PBX or its operators have a trusted signing certificate (CA) for the domain, and can use that certificate to sign a shorter- lived certificate that will be delegated to SSP allowing the SSP to, for a limited duration, appear to be authoritative for that domain when contacted using the procedures of RFC 3263 and SIPS. Of course, we need a mechanism for pushing that cert from PBX to SSP. We may also need to talk about service-dispatch. The SSP MUST NOT do per-user service dispatch using Service-Route, since all users registered with a single request get the same Service-Route. -- Dean From adam@nostrum.com Tue Jan 26 07:13:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E2B3A6840 for ; Tue, 26 Jan 2010 07:13:46 -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, 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 jwMNY3KKoD-6 for ; Tue, 26 Jan 2010 07:13:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D2BF13A67D9 for ; Tue, 26 Jan 2010 07:13:40 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QFDkt8020082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 09:13:46 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F06AA.2000503@nostrum.com> Date: Tue, 26 Jan 2010 09:13:46 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000900040403070606050807" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:13:46 -0000 This is a multi-part message in MIME format. --------------000900040403070606050807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/26/10 08:53, Jan 26, Hadriel Kaplan wrote: > > I suggest we change the format of this meeting. Currently you have > Adam and I scheduled to deliver presentations on our drafts, but > nothing's changed with them afaik. The email discussion so far has > not really been specific to the drafts -- most of the topics have been > applicable no matter which draft model is used. > > So I suggest we just go through John's requirements and then discuss > the email topics, and skip the drafts. > > It appears the topics have been: > > 1) What to do with the req-uri: leave alone, contact-routing, or > re-targeting. > > 2) Which entity "owns" or is responsible for the Enterprise domain. > > 3) Whether to encode the implicitly registered AoR's in the > REGISTER/PUBLISH transaction, or not. > > Oddly the one topic I thought would be the hot one from the last > meeting, namely GRUU, has not been discussed on the mailing list afaict. > I did mention it briefly yesterday, at the bottom of the message I sent to Richard. But no mechanism has been discussed so far, largely because of the conversations around the larger issues. I'm trying to pull together more of a list around issues we've discussed so far, and hope to have some kind of slides that go over some of the relevant points. So far, the issues I've identified from conversations include your three, plus: 1. Implicit versus Explicit indication of multiple AORs 2. Contacts: to map or not to map 3. User Authentication vs. Route Authentication (see http://www.ietf.org/mail-archive/web/martini/current/msg00225.html and http://www.ietf.org/mail-archive/web/martini/current/msg00227.html) 4. Transport issues: Does this need to work over UDP? There might be others; I'm still digging through messages and the rusty corners of my brain. /a --------------000900040403070606050807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/26/10 08:53, Jan 26, Hadriel Kaplan wrote:

I suggest we change the format of this meeting.  Currently you have Adam and I scheduled to deliver presentations on our drafts, but nothing’s changed with them afaik.  The email discussion so far has not really been specific to the drafts – most of the topics have been applicable no matter which draft model is used.

So I suggest we just go through John’s requirements and then discuss the email topics, and skip the drafts.

 

It appears the topics have been:

1)       What to do with the req-uri: leave alone, contact-routing, or re-targeting.

2)       Which entity “owns” or is responsible for the Enterprise domain.

3)       Whether to encode the implicitly registered AoR’s in the REGISTER/PUBLISH transaction, or not.

 

Oddly the one topic I thought would be the hot one from the last meeting, namely GRUU, has not been discussed on the mailing list afaict.


I did mention it briefly yesterday, at the bottom of the message I sent to Richard. But no mechanism has been discussed so far, largely because of the conversations around the larger issues.

I'm trying to pull together more of a list around issues we've discussed so far, and hope to have some kind of slides that go over some of the relevant points. So far, the issues I've identified from conversations include your three, plus:
  1. Implicit versus Explicit indication of multiple AORs
  2. Contacts: to map or not to map
  3. User Authentication vs. Route Authentication (see http://www.ietf.org/mail-archive/web/martini/current/msg00225.html and http://www.ietf.org/mail-archive/web/martini/current/msg00227.html)
  4. Transport issues: Does this need to work over UDP?

There might be others; I'm still digging through messages and the rusty corners of my brain.

/a

--------------000900040403070606050807-- From BLINDSAY@nortel.com Tue Jan 26 07:16:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BFD03A68C7 for ; Tue, 26 Jan 2010 07:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 do0-FEKcBr0Q for ; Tue, 26 Jan 2010 07:16:32 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A7EFC3A68B7 for ; Tue, 26 Jan 2010 07:16:31 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0QFGLI26441; Tue, 26 Jan 2010 15:16:23 GMT 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, 26 Jan 2010 10:14:41 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkg References: From: "Brian Lindsay" To: "Hadriel Kaplan" , Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:16:33 -0000 Hi Hadriel, I don't think this needs to be spelled out in the draft. There may be specific solutions/architectures like IMS that would use this, and that's OK, but I don't believe this is central to the mechanism/interface in the draft. Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Tuesday, January 26, 2010 10:02 AM To: martini@ietf.org Subject: [martini] Listing the implicitly registered AoR's On the topic of listing implicitly registered AoR's (what has been done so far in P-Associated-URI), the emails on this seem to focus on either requiring it, or not at all. But there was a third option proposed by someone on the last virtual meeting call: use reg-event for that. In other words, don't put them in a PAU/whatever of the REGISTER (or PUBLISH) request or response. Instead, use the subscription for reg-event to list them. In the P-CSCF/edge-proxy case, the edge-proxy itself can subscribe to that package after the IP-PBX has registered itself. That seemed like a good compromise to me. (I preferred having it in the REGISTER response, but we can't have everything :) -hadriel _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From dean.willis@softarmor.com Tue Jan 26 07:23:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3865F3A6807 for ; Tue, 26 Jan 2010 07:23:05 -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 gK6aRhjWV1i3 for ; Tue, 26 Jan 2010 07:23:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 086DE3A681A for ; Tue, 26 Jan 2010 07:23:01 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QFN9m1016553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:23:10 -0600 Message-Id: <30562FC0-E7C1-471C-8773-18025389A05D@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B5DED83.2000407@nostrum.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: Tue, 26 Jan 2010 09:23:04 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B59DD3F.5030509@nostrum.com> <4B5DED83.2000407@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: Hadriel Kaplan , "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:23:05 -0000 On Jan 25, 2010, at 1:14 PM, Adam Roach wrote: > On 1/25/10 3:25 AM, Elwell, John wrote: >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> >>> ... >>> >>> Now, if we stick with the "the SSP does not rewrite the URI" >>> approach that Keith and John are rather adamant about, the >>> only thing we can really do in terms of "these numbers go >>> here, those numbers go there" looks something like this: >>> >> [JRE] Although I may not have made myself clear, what I really am >> adamant about is preserving the identity of the target user in the >> Request-URI. So if the domain part is changed, but the user-info >> part is retained, that would be satisfactory. >> > ... >>> This is great! Now we're using REGISTER to put an AOR to >>> Contact mapping in place (like it always has) instead of >>> using it to install rules to override normal RFC3263 >>> handling. Best of all, we're not saying "ignore DNS and use >>> this alternate mechanism for turning names into addresses" >>> like we have to with the "domain routing" approach. >>> >> [JRE] This would seem reasonable. The point is, if the PBX >> registers as its contact address pbx123@10.15.2.4, then inbound >> INVITE requests would not contain that same value in the Request- >> URI, but would contain something like dsmith@10.15.2.4. The >> identity of the target is retained. So I think we are in agreement. >> Hold on here. If the SSP is doing contact routing, which is what I think Adam is proposing, then the inbound INVITE request might be transformed from sip:dsmith@example.com to sip:pbx123@10.15.2.4. If however the SSP is doing "something that is not contact routing", aka "just plain loose routing", then it would transform neither the user nor domain parts of the request, which would then arrive at PBX with a R-URI of "dsmith@example.com". But what I think you're proposing is yet another programmatic transformation, where the user-part of the r-URI is held constant but the domain-part of the r-URI is transformed to match the domain-part of the To: URI from the REGISTER. As has been pointed out, this requires that the PBX use a different contact URI for each domain being registered. But the restriction is really even tighter: the PBX MUST use a different domain part for the Contact registered for each domain, as lack of preservation of the registered user-part means it has to differentiate between local domains based only on the domain part of the registered contacts. So this means that if the PBX supports multiple domains, then it cannot register using an IP address as a domain part unless it also has a separate IP address for each domain. Of course, it could use a different DNS name, but we sort of have the assumption that the PBX doesn't really have a useable domain name; if it did, then we'd just use RFC 3263 procedures combined with dynamic DNS. And presumably if PBX doesn't have a single useable DNS name, then it doesn't have a different one for each local domain. -- Dean From dean.willis@softarmor.com Tue Jan 26 07:32:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D053A6823 for ; Tue, 26 Jan 2010 07:32:21 -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 QWly3+Pm+B03 for ; Tue, 26 Jan 2010 07:32:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6FDCD3A6807 for ; Tue, 26 Jan 2010 07:32:20 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QFWOKO016650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:32:27 -0600 From: Dean Willis To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 09:32:18 -0600 X-Mailer: Apple Mail (2.936) Cc: Bernard Aboba , martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:32:21 -0000 On Jan 25, 2010, at 1:16 PM, Spencer Dawkins wrote: > Bernard is asking a much better-formed version of my question - > thanks for clarifying! > > Spencer > > >> Spencer said: >> >> "> - The mechanism SHOULD scale to PBXs of several thousand AORs. >> >> I was hoping that someone else would ask about this one, but no one >> else >> has. >> >> Does anyone on this list actually NEED mass registration for several >> thousand AORs?" >> >> [BA] Question: Are there existing installations that use "implicit >> registration" at this kind of scale? >> Or alternatively, are there specific customers that have made this >> request? A single Cisco Call Manager server might support ten thousand users, and I suspect that such a server at a large enterprise (or local government facility: the Dallas city offices use one) is a potential customer for SSP services. Given that we have IPv4 address space exhaustion and there's no chance of IPv6 happening any time soon, it wouldn't surprise me to see large (10,000 plus seat) organizations that don't have a single public IP address in their entire organization, but instead are issues an ISP- routable 10.x.x.x subnet for their access routers by their ISP. Address space exhaustion is a wet-dream opportunity for vendors of SBC- like dynamic-access services for all sorts of things, not just SIP. Why not have dynamic registration between an enterprise web server and a carrier-hosted web proxy, such that clients use regular DNS procedures find the carrier-hosted proxy which then tunnels the request to the enterprise web server? Wouldn't THAT have ugly security properties! But it's exactly the same thing we're doing to the security properties in SIP with domain registration. I think I'm going to go patent that dynamic HTTP-proxy binding stuff; it's evil enough that I expect somebody to bring it to market. -- Dean From HKaplan@acmepacket.com Tue Jan 26 07:32:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0A03A63EC for ; Tue, 26 Jan 2010 07:32:23 -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 btG6lTWqzV06 for ; Tue, 26 Jan 2010 07:32:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AC19B3A6823 for ; Tue, 26 Jan 2010 07:32:22 -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; Tue, 26 Jan 2010 10:32:32 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:32:32 -0500 From: Hadriel Kaplan To: "martini@ietf.org" Date: Tue, 26 Jan 2010 10:32:30 -0500 Thread-Topic: The much maligned Request-URI Thread-Index: AcqenMYLL2zn1Yg1TNO+1bnkx+ZXMQ== 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: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:32:24 -0000 Howdy, The topic of what to do with that pesky Req-uri seems to be going round and= round. There are 3 camps afaict: 1) Leave it alone - completely alone. 2) Contact-route it: replace it with the Registered contact, where "Registe= red contact" may be a URI indicated in a body list per AoR, or regex-style = formula. 3) Change the host portion only, based on the contact-uri host or a provisi= oned domain name, leave the rest alone (user and params). I don't think Option-1 is a real option. As far as I know, in virtually al= l cases of IP-PBX trunking I've been involved with, by the time the request= gets to the IP-PBX, the req-uri's domain/host portion identifies the IP-PB= X's domain or host/IP. It may not be the routing proxy-registrar which doe= s it, but a middlebox instead... but it will get changed if it wasn't alrea= dy right. =20 That's consistent with what *should* happen, because if the request was sip= :foobar@ssp.com and was routed to pbx.com, then it got *retargeted*. Lucki= ly (or not) retargeting rules are basically completely open in 3261. We ca= n do whatever magic we want to. There have been some threads that changing "sip:foobar@ssp.com" to "sip:foo= bar@pbx.com" *blindly* is broken for anything but E.164 because foobar may = be someone different for pbx.com. I think that's a red herring argument. = In what way, shape or form could the SSP have possibly *blindly* retargeted= foobar@ssp.com to foobar@pbx.com?? Clearly the SSP must have had some ret= argeting entry for "foobar@ssp.com" - the whole thing, not just the host. = The same is true of E.164's - the SSP can't/won't send all E.164's to pbx.c= om, just the list of ones for the pbx. So ISTM what we're really talking about is whether the PBX should be able t= o provision the retargeting rules themselves in the SSP through the registr= ation mechanism (ie, a body list or regex formula), or whether we should le= ave it as just pre-provisioned and simply document that a retargeting MUST = occur to the PBX's domain/host. Personally I vote for leave it pre-provisioned, because I don't want to tro= ubleshoot weird PBX implementations putting crap in a body list. I know th= e SSP side can screw up too, but it's easier to manage. (but then of course= I'd say that) -hadriel From HKaplan@acmepacket.com Tue Jan 26 07:34:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80F0B3A6828 for ; Tue, 26 Jan 2010 07:34:28 -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 itiUsYJkdpeU for ; Tue, 26 Jan 2010 07:34:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 73B563A6823 for ; Tue, 26 Jan 2010 07:34:27 -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; Tue, 26 Jan 2010 10:34:37 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:34:34 -0500 From: Hadriel Kaplan To: Brian Lindsay , "martini@ietf.org" Date: Tue, 26 Jan 2010 10:34:29 -0500 Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkgAADKxIA= Message-ID: References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.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: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:34:28 -0000 Hi Brian, I _think_ that's consistent with using reg-event, because we wouldn't docum= ent a requirement to use reg-event, just note that it could be used for tha= t purpose (if even that). -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Brian Lindsay > Sent: Tuesday, January 26, 2010 10:15 AM > To: Hadriel Kaplan; martini@ietf.org > Subject: Re: [martini] Listing the implicitly registered AoR's >=20 > Hi Hadriel, >=20 > I don't think this needs to be spelled out in the draft. There may be > specific solutions/architectures like IMS that would use this, and > that's OK, but I don't believe this is central to the > mechanism/interface in the draft. >=20 > Thanks > Brian >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Tuesday, January 26, 2010 10:02 AM > To: martini@ietf.org > Subject: [martini] Listing the implicitly registered AoR's >=20 > On the topic of listing implicitly registered AoR's (what has been done > so far in P-Associated-URI), the emails on this seem to focus on either > requiring it, or not at all. But there was a third option proposed by > someone on the last virtual meeting call: use reg-event for that. >=20 > In other words, don't put them in a PAU/whatever of the REGISTER (or > PUBLISH) request or response. Instead, use the subscription for > reg-event to list them. In the P-CSCF/edge-proxy case, the edge-proxy > itself can subscribe to that package after the IP-PBX has registered > itself. >=20 > That seemed like a good compromise to me. (I preferred having it in the > REGISTER response, but we can't have everything :) >=20 > -hadriel > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Tue Jan 26 07:37:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1635628C0D7 for ; Tue, 26 Jan 2010 07:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 bF6XfbVFcMxo for ; Tue, 26 Jan 2010 07:37:41 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by core3.amsl.com (Postfix) with ESMTP id D970128C0CF for ; Tue, 26 Jan 2010 07:37:40 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.74]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 07:37:51 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Spencer Dawkins'" , References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Date: Tue, 26 Jan 2010 07:39:10 -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: AcqejfwQ9WLGAezFRP+J3BSRH20CrAADwPdA Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 15:37:51.0362 (UTC) FILETIME=[851A2E20:01CA9E9D] Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:37:42 -0000 Spencer said: "The problem with user@enterprise.com is that requests from outside the service provider to this AOR would go straight to the SIP-PBX without traversing any service provider proxy - unless we dork with two-faced DNS, etc." [BA] Doesn't this depend on whether the DNS SRV RRs for "enterprise.com" point to the service provider? If so, then shouldn't requests go to the SP, even if the A/AAAA RRs are dynamically updated to point to the SIP-PBX? From adam@nostrum.com Tue Jan 26 07:39:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82CB33A6828 for ; Tue, 26 Jan 2010 07:39: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=[AWL=-0.000, BAYES_00=-2.599, 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 bMcP4y4BN8xr for ; Tue, 26 Jan 2010 07:38:59 -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 94C6E3A6842 for ; Tue, 26 Jan 2010 07:38:58 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QFd7kG022062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Jan 2010 09:39:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F0C9B.1010908@nostrum.com> Date: Tue, 26 Jan 2010 09:39:07 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010303090508060500000409" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:39:00 -0000 This is a multi-part message in MIME format. --------------010303090508060500000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: > That's consistent with what *should* happen, because if the request was sip:foobar@ssp.com and was routed to pbx.com, then it got *retargeted*. Luckily (or not) retargeting rules are basically completely open in 3261. We can do whatever magic we want to. > That's only true for a proxy that is responsible for the R-URI. Everyone else is pretty tightly constrained in what they can do -- basically, they can add Route headers, but they are forbidden from retargeting. RFC 3261 has at least two normative statements on the topic: "A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for." "If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding" > There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com. I think that's a red herring argument. In what way, shape or form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com?? Clearly the SSP must have had some retargeting entry for "foobar@ssp.com" - the whole thing, not just the host. I agree. The prospect of ignoring the domain and treating the user as a unique key is highly problematic. > So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP The SSP can't retarget unless is responsible for the domain. But if the SSP is responsible for the domain, then the PBX can't retarget the requests once they arrive, which means they can't send them to the proper terminal. Which is why we need to nail down domain responsibility. /a --------------010303090508060500000409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: 
That's consistent with what *should* happen, because if the request was sip:foobar@ssp.com and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically completely open in 3261.  We can do whatever magic we want to.

That's only true for a proxy that is responsible for the R-URI. Everyone else is pretty tightly constrained in what they can do -- basically, they can add Route headers, but they are forbidden from retargeting. RFC 3261 has at least two normative statements on the topic:

"A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding"


There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com??  Clearly the SSP must have had some retargeting entry for "foobar@ssp.com" - the whole thing, not just the host.

I agree. The prospect of ignoring the domain and treating the user as a unique key is highly problematic.

So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP

The SSP can't retarget unless is responsible for the domain.

But if the SSP is responsible for the domain, then the PBX can't retarget the requests once they arrive, which means they can't send them to the proper terminal.

Which is why we need to nail down domain responsibility.

/a
--------------010303090508060500000409-- From HKaplan@acmepacket.com Tue Jan 26 07:39:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AE63A683E for ; Tue, 26 Jan 2010 07:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 j4QEd6dillOw for ; Tue, 26 Jan 2010 07:38:55 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DB73A3A67B3 for ; Tue, 26 Jan 2010 07:38:54 -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; Tue, 26 Jan 2010 10:39:04 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:39:04 -0500 From: Hadriel Kaplan To: Adam Roach Date: Tue, 26 Jan 2010 10:39:02 -0500 Thread-Topic: [martini] Request for Slides -- Take Two Thread-Index: Acqemjmrze5R7AncS2SCWE7mgMkKQgAA2H4A Message-ID: References: <4B5F06AA.2000503@nostrum.com> In-Reply-To: <4B5F06AA.2000503@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B2Email_" MIME-Version: 1.0 Cc: Bernard Aboba , "martini@ietf.org" Subject: Re: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:39:00 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B2Email_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for that - I missed the emails on authentication. They made me laug= h out loud and I needed that. :) -hadriel ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, January 26, 2010 10:14 AM To: Hadriel Kaplan Cc: Bernard Aboba; martini@ietf.org Subject: Re: [martini] Request for Slides -- Take Two On 1/26/10 08:53, Jan 26, Hadriel Kaplan wrote: I suggest we change the format of this meeting. Currently you have Adam an= d I scheduled to deliver presentations on our drafts, but nothing's changed= with them afaik. The email discussion so far has not really been specific= to the drafts - most of the topics have been applicable no matter which dr= aft model is used. So I suggest we just go through John's requirements and then discuss the em= ail topics, and skip the drafts. It appears the topics have been: What to do with the req-uri: leave alone, contact-routing, or re-targeting. Which entity "owns" or is responsible for the Enterprise domain. Whether to encode the implicitly registered AoR's in the REGISTER/PUBLISH t= ransaction, or not. Oddly the one topic I thought would be the hot one from the last meeting, n= amely GRUU, has not been discussed on the mailing list afaict. I did mention it briefly yesterday, at the bottom of the message I sent to = Richard. But no mechanism has been discussed so far, largely because of the= conversations around the larger issues. I'm trying to pull together more of a list around issues we've discussed so= far, and hope to have some kind of slides that go over some of the relevan= t points. So far, the issues I've identified from conversations include you= r three, plus: 1. Implicit versus Explicit indication of multiple AORs 2. Contacts: to map or not to map 3. User Authentication vs. Route Authentication (see http://www.ietf.org/= mail-archive/web/martini/current/msg00225.html and http://www.ietf.org/mail= -archive/web/martini/current/msg00227.html) 4. Transport issues: Does this need to work over UDP? There might be others; I'm still digging through messages and the rusty cor= ners of my brain. /a --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B2Email_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for that – I missed the e= mails on authentication.  They made me laugh out loud and I needed that. J<= /font>

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2= 010 10:14 AM
To: Hadriel Kaplan
Cc: Bernard Aboba; martini@ietf.org
Subject: Re: [martini] Reque= st for Slides -- Take Two<= o:p>

 

On 1/26/10 08:53, Jan 26, Hadriel Kaplan wrote:

I suggest we change the format of this meeting.  Currently you have Adam and I scheduled to deliver presentations on o= ur drafts, but nothing’s changed with them afaik.  The email discus= sion so far has not really been specific to the drafts – most of the topics h= ave been applicable no matter which draft model is used.<= o:p>

So I suggest we just go through John&#= 8217;s requirements and then discuss the email topics, and skip the drafts.<= /u1:p>

 =

It appears the topics have been:=

What to do with the req-uri: leave alone, contact-routing, or re-targeting.

Which entity “owns” or is responsible for the Enterprise domain.

Whether to encode the implicitly registered AoR’s in the REGISTER/PUBLISH transaction, or not.=

 =

Oddly the one topic I thought would be= the hot one from the last meeting, namely GRUU, has not been discussed on the mailing list afaict.

=
I did mention it brie= fly yesterday, at the bottom of the message I sent to Richard. But no mechanism= has been discussed so far, largely because of the conversations around the larg= er issues.

I'm trying to pull together more of a list around issues we've discussed so far, and hope to have some kind of slides that go over some of the relevant points. So far, the issues I've identified from conversations include your three, plus:

  1. Implicit vers= us Explicit indication of multiple AORs
  2. Contacts: to = map or not to map
  3. User Authenti= cation vs. Route Authentication (see http://www.ietf.org/mail-archive/web/martini/current/msg00225.html and http://www.ietf.org/mail-archive/web/martini/current/msg00227.html)
  4. Transport iss= ues: Does this need to work over UDP?


There might be others; I'm still digging through messages and the rusty cor= ners of my brain.

/a

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B2Email_-- From bruno.chatras@orange-ftgroup.com Tue Jan 26 07:39:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F0A3A683F for ; Tue, 26 Jan 2010 07:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 vt01SvmawlX3 for ; Tue, 26 Jan 2010 07:39:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 03CAB3A6828 for ; Tue, 26 Jan 2010 07:39:31 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BEA672781D4; Tue, 26 Jan 2010 16:39:40 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A599B35C016; Tue, 26 Jan 2010 16:39:40 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:39:41 +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, 26 Jan 2010 16:39:40 +0100 Message-ID: <4787_1264520380_4B5F0CBC_4787_2770_1_9ECCF01B52E7AB408A7EB85352642141010535B4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqenMYLL2zn1Yg1TNO+1bnkx+ZXMQAAMdww References: From: To: , X-OriginalArrivalTime: 26 Jan 2010 15:39:41.0348 (UTC) FILETIME=[C6A8B640:01CA9E9D] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.151537 Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:39:33 -0000 =20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : mardi 26 janvier 2010 16:33 > =C0 : martini@ietf.org > Objet : [martini] The much maligned Request-URI >=20 > Howdy, > The topic of what to do with that pesky Req-uri seems to be=20 > going round and round. >=20 > There are 3 camps afaict: > 1) Leave it alone - completely alone. > 2) Contact-route it: replace it with the Registered contact,=20 > where "Registered contact" may be a URI indicated in a body=20 > list per AoR, or regex-style formula. > 3) Change the host portion only, based on the contact-uri=20 > host or a provisioned domain name, leave the rest alone (user=20 > and params). >=20 > I don't think Option-1 is a real option. As far as I know,=20 > in virtually all cases of IP-PBX trunking I've been involved=20 > with, by the time the request gets to the IP-PBX, the=20 > req-uri's domain/host portion identifies the IP-PBX's domain=20 > or host/IP. It may not be the routing proxy-registrar which=20 > does it, but a middlebox instead... but it will get changed=20 > if it wasn't already right.=20=20 >=20 =3D=3D>BC: This statement sounds strange to me as I have seen cases where t= he middlebox does the opposite: overrides the Request-URI with the contents= of a P-Called-Party-Id header field so as to restore the initial value Req= uest-URI. > That's consistent with what *should* happen, because if the=20 > request was sip:foobar@ssp.com and was routed to pbx.com,=20 > then it got *retargeted*. Luckily (or not) retargeting rules=20 > are basically completely open in 3261. We can do whatever=20 > magic we want to. >=20 > There have been some threads that changing=20 > "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly* is=20 > broken for anything but E.164 because foobar may be someone=20 > different for pbx.com. I think that's a red herring=20 > argument. In what way, shape or form could the SSP have=20 > possibly *blindly* retargeted foobar@ssp.com to=20 > foobar@pbx.com?? Clearly the SSP must have had some=20 > retargeting entry for "foobar@ssp.com" - the whole thing, not=20 > just the host. The same is true of E.164's - the SSP=20 > can't/won't send all E.164's to pbx.com, just the list of=20 > ones for the pbx. >=20 > So ISTM what we're really talking about is whether the PBX=20 > should be able to provision the retargeting rules themselves=20 > in the SSP through the registration mechanism (ie, a body=20 > list or regex formula), or whether we should leave it as just=20 > pre-provisioned and simply document that a retargeting MUST=20 > occur to the PBX's domain/host. >=20 > Personally I vote for leave it pre-provisioned, because I=20 > don't want to troubleshoot weird PBX implementations putting=20 > crap in a body list. I know the SSP side can screw up too,=20 > but it's easier to manage. (but then of course I'd say that) >=20 > -hadriel >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Tue Jan 26 07:40:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD0D3A686D for ; Tue, 26 Jan 2010 07:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 W0GqxDb0a0Rd for ; Tue, 26 Jan 2010 07:40:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id AABD43A6842 for ; Tue, 26 Jan 2010 07:40:38 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 43D332AC950; Tue, 26 Jan 2010 16:40:48 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 24B5515803E; Tue, 26 Jan 2010 16:40:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:40:48 +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, 26 Jan 2010 16:40:47 +0100 Message-ID: <27427_1264520448_4B5F0D00_27427_48986_1_9ECCF01B52E7AB408A7EB85352642141010535BA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: AcqejfwQ9WLGAezFRP+J3BSRH20CrAADwPdAAAA1DWA= References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 26 Jan 2010 15:40:48.0186 (UTC) FILETIME=[EE7F61A0:01CA9E9D] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.140320 Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:40:40 -0000 Yes. I was about to provide the same reply. > -----Message d'origine----- > De : Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Envoy=E9 : mardi 26 janvier 2010 16:39 > =C0 : 'Spencer Dawkins'; CHATRAS Bruno RD-CORE-ISS > Cc : martini@ietf.org > Objet : RE: [martini] Enumerating AORs/contacts >=20 > Spencer said: >=20 > "The problem with user@enterprise.com is that requests from=20 > outside the service provider to this AOR would go straight to=20 > the SIP-PBX without traversing any service provider proxy -=20 > unless we dork with two-faced DNS, etc." >=20 > [BA] Doesn't this depend on whether the DNS SRV RRs for=20 > "enterprise.com" > point to the service provider? If so, then shouldn't=20 > requests go to the SP, even if the A/AAAA RRs are dynamically=20 > updated to point to the SIP-PBX? >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From HKaplan@acmepacket.com Tue Jan 26 07:42:37 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F413A6828 for ; Tue, 26 Jan 2010 07:42:37 -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 rfPtRSAXGY4k for ; Tue, 26 Jan 2010 07:42:36 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4C4263A6869 for ; Tue, 26 Jan 2010 07:42:36 -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; Tue, 26 Jan 2010 10:42:45 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:42:45 -0500 From: Hadriel Kaplan To: Spencer Dawkins , "bruno.chatras@orange-ftgroup.com" , "john.elwell@siemens-enterprise.com" , "adam@nostrum.com" Date: Tue, 26 Jan 2010 10:42:44 -0500 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqejhep7c7FB5VaSW+oGpyBdLzimQAD89ZA Message-ID: References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:42:37 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Tuesday, January 26, 2010 8:47 AM >=20 > The problem with user@enterprise.com is that requests from outside the > service provider to this AOR would go straight to the SIP-PBX without > traversing any service provider proxy - unless we dork with two-faced DNS= , > etc. *We* (martini) won't be dorking with anything. How a request got to the SS= P is effectively out of scope for this WG, right? For all I know, the requ= est originated in the SSP. The question isn't how it got to the SSP - the = question is what the SSP should do about it once it gets it. :) -hadriel From bernard_aboba@hotmail.com Tue Jan 26 07:43:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F57D3A6828 for ; Tue, 26 Jan 2010 07:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.164, 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 VkHpq7pSg0JF for ; Tue, 26 Jan 2010 07:43:00 -0800 (PST) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by core3.amsl.com (Postfix) with ESMTP id 1DC9A3A6869 for ; Tue, 26 Jan 2010 07:43:00 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.73]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 07:43:10 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" , "'Hadriel Kaplan'" References: <4B5F06AA.2000503@nostrum.com> In-Reply-To: <4B5F06AA.2000503@nostrum.com> Date: Tue, 26 Jan 2010 07:44:29 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01CA9E5B.646DF220" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqemin779WRLeEpTye2dp7fA5sx0gABCFIg Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 15:43:10.0474 (UTC) FILETIME=[434ECEA0:01CA9E9E] Cc: martini@ietf.org Subject: Re: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:43:01 -0000 ------=_NextPart_000_010B_01CA9E5B.646DF220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Adam said: "I'm trying to pull together more of a list around issues we've discussed so far, and hope to have some kind of slides that go over some of the relevant points. So far, the issues I've identified from conversations include your three, plus: 1. Implicit versus Explicit indication of multiple AORs 2. Contacts: to map or not to map 3. User Authentication vs. Route Authentication (see http://www.ietf.org/mail-archive/web/martini/current/msg00225.html and http://www.ietf.org/mail-archive/web/martini/current/msg00227.html) 4. Transport issues: Does this need to work over UDP? There might be others; I'm still digging through messages and the rusty corners of my brain." [BA] This sounds good. I'll change the agenda to remove the author presentations and allocate the time to this discussion instead. ------=_NextPart_000_010B_01CA9E5B.646DF220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adam said:

 

"I'm trying to pull together more of a list around issues we've discussed so = far, and hope to have some kind of slides that go over some of the relevant = points. So far, the issues I've identified from conversations include your = three, plus:

  1. Implicit versus Explicit indication of multiple AORs
  2. Contacts: to map or not to map
  3. User Authentication vs. Route Authentication (see http://www.ietf.org/mail-archive/web/martini/current/msg00225.html= and http://www.ietf.org/mail-archive/web/martini/current/msg00227.html= )
  4. Transport issues: Does this need to work over UDP?


There might be others; I'm still digging through messages and the rusty = corners of my brain."

[BA] This sounds = good.   I'll change the agenda to remove the author presentations and allocate = the time to this discussion instead.

------=_NextPart_000_010B_01CA9E5B.646DF220-- From bruno.chatras@orange-ftgroup.com Tue Jan 26 07:44:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377103A683F for ; Tue, 26 Jan 2010 07:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 rxikJUbXr9z2 for ; Tue, 26 Jan 2010 07:44:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 26BE43A6828 for ; Tue, 26 Jan 2010 07:44:33 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 4421E1B8797; Tue, 26 Jan 2010 16:44:43 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7355F15803E; Tue, 26 Jan 2010 16:44:42 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:44: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, 26 Jan 2010 16:44:41 +0100 Message-ID: <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkgAADKxIAAAEjFIA== References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 26 Jan 2010 15:44:43.0146 (UTC) FILETIME=[7A8B6EA0:01CA9E9E] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.133319 Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:44:34 -0000 I assume that IMS-based networks would continue to use P-Associated-URI in = their "closed" environnements rather than use an extended reg-event package= . I'v not seen any proposal to deprecate RFC3455 anyway... > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : mardi 26 janvier 2010 16:34 > =C0 : Brian Lindsay; martini@ietf.org > Objet : Re: [martini] Listing the implicitly registered AoR's >=20 >=20 > Hi Brian, > I _think_ that's consistent with using reg-event, because we=20 > wouldn't document a requirement to use reg-event, just note=20 > that it could be used for that purpose (if even that). >=20 > -hadriel >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Brian Lindsay > > Sent: Tuesday, January 26, 2010 10:15 AM > > To: Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] Listing the implicitly registered AoR's > >=20 > > Hi Hadriel, > >=20 > > I don't think this needs to be spelled out in the draft.=20 > There may=20 > > be specific solutions/architectures like IMS that would use=20 > this, and=20 > > that's OK, but I don't believe this is central to the=20 > > mechanism/interface in the draft. > >=20 > > Thanks > > Brian > >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Hadriel Kaplan > > Sent: Tuesday, January 26, 2010 10:02 AM > > To: martini@ietf.org > > Subject: [martini] Listing the implicitly registered AoR's > >=20 > > On the topic of listing implicitly registered AoR's (what has been=20 > > done so far in P-Associated-URI), the emails on this seem=20 > to focus on=20 > > either requiring it, or not at all. But there was a third option=20 > > proposed by someone on the last virtual meeting call: use=20 > reg-event for that. > >=20 > > In other words, don't put them in a PAU/whatever of the REGISTER (or > > PUBLISH) request or response. Instead, use the subscription for=20 > > reg-event to list them. In the P-CSCF/edge-proxy case, the=20 > edge-proxy=20 > > itself can subscribe to that package after the IP-PBX has=20 > registered=20 > > itself. > >=20 > > That seemed like a good compromise to me. (I preferred having it in=20 > > the REGISTER response, but we can't have everything :) > >=20 > > -hadriel > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From HKaplan@acmepacket.com Tue Jan 26 07:44:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC03C3A688C for ; Tue, 26 Jan 2010 07:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 gowM2yoWLy3g for ; Tue, 26 Jan 2010 07:44:47 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 551403A681B for ; Tue, 26 Jan 2010 07:44:47 -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; Tue, 26 Jan 2010 10:44:57 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:44:56 -0500 From: Hadriel Kaplan To: Adam Roach , "martini@ietf.org" Date: Tue, 26 Jan 2010 10:44:56 -0500 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqendfL4PPvwNcgSNikMcspPEAzXAAAG5qA Message-ID: References: <4B5F0C9B.1010908@nostrum.com> In-Reply-To: <4B5F0C9B.1010908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B4Amail_" MIME-Version: 1.0 Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:44:53 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B4Amail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry I should have been explicit about the context. The context was the S= SP receives a request for "sip:foobar@ssp.com". The SSP is authoritative f= or ssp.com. It retargets to pbx.com. -hadriel ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Tuesday, January 26, 2010 10:39 AM To: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: That's consistent with what *should* happen, because if the request was sip= :foobar@ssp.com and was routed to pbx.com, then = it got *retargeted*. Luckily (or not) retargeting rules are basically comp= letely open in 3261. We can do whatever magic we want to. That's only true for a proxy that is responsible for the R-URI. Everyone el= se is pretty tightly constrained in what they can do -- basically, they can= add Route headers, but they are forbidden from retargeting. RFC 3261 has a= t least two normative statements on the topic: "A proxy MUST NOT add additional targets to the target set if the Request-U= RI of the original request does not indicate a resource this proxy is respo= nsible for." "If the domain of the Request-URI indicates a domain this element is not re= sponsible for, the Request-URI MUST be placed into the target set as the on= ly target, and the element MUST proceed to the task of Request Forwarding" There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly= * is broken for anything but E.164 because foobar may be someone different = for pbx.com. I think that's a red herring argument. In what way, shape or= form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com?? Clearly the S= SP must have had some retargeting entry for "foobar@ssp.com" - the whole thing, not just the host. I agree. The prospect of ignoring the domain and treating the user as a uni= que key is highly problematic. So ISTM what we're really talking about is whether the PBX should be able t= o provision the retargeting rules themselves in the SSP The SSP can't retarget unless is responsible for the domain. But if the SSP is responsible for the domain, then the PBX can't retarget t= he requests once they arrive, which means they can't send them to the prope= r terminal. Which is why we need to nail down domain responsibility. /a --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B4Amail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry I should have been explicit abou= t the context.  The context was the SSP receives a request for “si= p:foobar@ssp.com”.  The SSP is authoritative for ssp.com.  It retargets to pbx.com.<= o:p>

 

-hadriel

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.or= g] On Behalf Of Adam Roach
Sent: Tuesday, January 26, 2= 010 10:39 AM
To: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: 

That's consistent with what *should* happen, bec=
ause if the request was sip:foobar@ssp.com and was routed to=
 pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rule=
s are basically completely open in 3261.  We can do whatever magic we =
want to.
 

=
That's only true for a proxy that is responsible for the R-URI. Everyone el= se is pretty tightly constrained in what they can do -- basically, they can ad= d Route headers, but they are forbidden from retargeting. RFC 3261 has at lea= st two normative statements on the topic:

"A proxy MUST NOT add additional targets to the ta= rget set if the Request-URI of the original request does not indicate a resource this proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is n= ot responsible for, the Request-URI MUST be placed into the target set as the = only target, and the element MUST proceed to the task of Request Forwarding"= ;



 
There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blin=
dly* is broken for anything but E.164 because foobar may be someone differe=
nt for pbx.com.  I think that's a red herring argument.  In what =
way, shape or form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com??  Clearly the SSP m=
ust have had some retargeting entry for "foobar@ssp.com" - the whole t=
hing, not just the host.

=
I agree. The prospect of ignoring the domain and treating the user as a uni= que key is highly problematic.


So ISTM what we're really talking about is wheth=
er the PBX should be able to provision the retargeting rules themselves in =
the SSP

=
The SSP can't retarget unless is responsible for the domain.

But if the SSP is responsible for the domain, then the PBX can't retarget t= he requests once they arrive, which means they can't send them to the proper terminal.

Which is why we need to nail down domain responsibility.

/a

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1B4Amail_-- From dean.willis@softarmor.com Tue Jan 26 07:44:53 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5BF3A681B for ; Tue, 26 Jan 2010 07:44: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 e0u1D+ttTvjq for ; Tue, 26 Jan 2010 07:44:52 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 649923A6876 for ; Tue, 26 Jan 2010 07:44:52 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QFj0b5016902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:45:01 -0600 Message-Id: <778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B5E2C00.4050407@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: Tue, 26 Jan 2010 09:44:54 -0600 References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:44:53 -0000 On Jan 25, 2010, at 5:40 PM, Paul Kyzivat wrote: > Spencer, > > I guess this needs to be segmented into separate issues, which you > have already more or less done: ... Excellent summary. One additional issue: Are the user-part identifiers restricted to being only encoded E.164 numbers? Or is a more general user-part syntax allowed? If we restrict ourselves to E.164 user-parts, then a lot of the complexity evaporates. This brings a related issue: Are we talking about sip: request URIs or tel: request URIs? -- Dean From john.elwell@siemens-enterprise.com Tue Jan 26 07:46:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39ED3A683F for ; Tue, 26 Jan 2010 07:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 NYumCA4xSS8v for ; Tue, 26 Jan 2010 07:46:43 -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 678B73A688D for ; Tue, 26 Jan 2010 07:46:43 -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-672246; Tue, 26 Jan 2010 16:46:52 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4794423F0294; Tue, 26 Jan 2010 16:46:52 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jan 2010 16:46:52 +0100 From: "Elwell, John" To: Brian Lindsay , Adam Roach Date: Tue, 26 Jan 2010 16:46:51 +0100 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAA53tIAAAskYgA== Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> <09B7DBFE70A9E24BBB21689DAD3A06141C3C88D0@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C3C88D0@zcarhxm1.corp.nortel.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: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:46:44 -0000 =20 > -----Original Message----- > From: Brian Lindsay [mailto:blindsay@nortel.com]=20 > Sent: 26 January 2010 14:41 > To: Elwell, John; Adam Roach > Cc: martini@ietf.org > Subject: RE: [martini] Enumerating AORs/contacts >=20 > Hi John, >=20 > I am not sure we have converged on this. There seemed to be a large > measure of agreement in earlier threads that the domain=20 > portion reflect > the domain name associated with the pbx. Which means that a > re-targetting may need to occur, but not necessarily that a "contact > routing" approach was being used. [JRE] I didn't particular like the term contact routing, but I guess you co= uld call it that, if the domain part of the contact URI (which would presum= ably match the domain part of the AORs being registered) is substituted for= the domain part of the Request-URI that arrives at the SP from the UAC, le= aving the user part unchanged. John >=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Tuesday, January 26, 2010 3:16 AM > To: Adam Roach > Cc: martini@ietf.org > Subject: [martini] Enumerating AORs/contacts >=20 > Changing the thread name to focus on another issue. >=20 > We seem to have converged on what Adam calls contact routing, which > basically says that the domain part of the Request-URI in an inbound > request should contain the domain part of the registered contact URI, > leaving the user part to identify the particular AOR. I think=20 > this does > indeed correspond to one of the practices seen in the wild at present. >=20 > This then leaves the question of whether we need to enumerate the > different user parts (and hence the AORs and their respective=20 > contacts), > either in the request (PBX to SP) or in the response (SP to PBX). My > question is whether we need this at all - the question=20 > whether it should > be in the request or the response can be addressed after we have > determined whether it is needed at all. >=20 > The argument for exchanging this information is to ensure that the two > sides are aligned, or at least to detect if there is=20 > misalignment. It is > probably not a mechanism for making changes to the set of user parts - > my opinion is that that is a provisioning issue and outside=20 > the scope of > MARTINI. >=20 > John >=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 25 January 2010 18:43 > > To: Elwell, John > > Cc: Dean Willis; martini@ietf.org; Hadriel Kaplan > > Subject: Re: [martini] Requirements - rev1 > >=20 > > On 1/25/10 10:13 AM, Elwell, John wrote: > > > > > > =20 > > >> -----Original Message----- > > >> From: Dean Willis [mailto:dean.willis@softarmor.com] > > >> > > >> Seriously, go back and look at Adam's arguments very=20 > carefully. He=20 > > >> might wear excessively colorful trousers from time to=20 > time, but I=20 > > >> think most of his arguments are spot-on. Please=20 > everybody: go read=20 > > >> draft-roach-martini-up-00 and pay very careful attention > > to Section 9. > > >> =20 > > > [JRE] I just read it again, and to be honest most of what > > it claims could also apply to a well-chosen REGISTER-based=20 > mechanism. > > > =20 > >=20 > > I agree, with emphasis on the terms "most" and "well-chosen." > >=20 > > I would not be entirely opposed to exploring what would constitute=20 > > "well-chosen," and then figuring out how to solve the problems that=20 > > fall outside the envelope covered by your term "most." > >=20 > > Based on your analysis post, your definition of "well-chosen"=20 > > inherently > > includes some programmatic mapping from AORs to Contacts=20 > ("one contact >=20 > > URI per AOR," implying contact routing, not domain=20 > routing). I think=20 > > that's a good place to start working from. > >=20 > > Don't get hung up on martini-up's proposal to use PUBLISH.=20 > > While it does > > solve a very real class of problems, that one relatively=20 > minor aspect=20 > > of the draft is not the most mechanism it proposes. The majority of=20 > > the problems it solves involve the explicit signaling of=20 > AORs in the=20 > > request, the definition of a mechanism that enables "one=20 > contact URI=20 > > per AOR," and the congruence with previous uses of REGISTER by=20 > > employing "contact routing" instead of "domain routing." > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From john.elwell@siemens-enterprise.com Tue Jan 26 07:47:01 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F793A683F for ; Tue, 26 Jan 2010 07:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 0fIVVU70DLe9 for ; Tue, 26 Jan 2010 07:46:59 -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 780EE3A6828 for ; Tue, 26 Jan 2010 07:46:59 -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-672045; Tue, 26 Jan 2010 16:47:09 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4763E1EB82B8; Tue, 26 Jan 2010 16:47:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jan 2010 16:47:09 +0100 From: "Elwell, John" To: "bruno.chatras@orange-ftgroup.com" , "adam@nostrum.com" Date: Tue, 26 Jan 2010 16:47:07 +0100 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqd7jGdf4sczZRaToyOA/04URkdNAAauT/gAAHnsIAAAcxW8AAA0PzgAAyK9WA= Message-ID: References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com><51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com><4B5DE61F.70302@nostrum.com> <20708_1264494564_4B5EA7E4_20708_85575_1_9ECCF01B52E7AB408A7EB853526421410101AC53@ftrdmel0.rd.francetelecom.fr> <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> 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: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:47:01 -0000 =20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com]=20 > Sent: 26 January 2010 09:50 > To: Elwell, John; adam@nostrum.com > Cc: martini@ietf.org > Subject: RE: [martini] Enumerating AORs/contacts >=20 > =20 >=20 > > -----Message d'origine----- > > De : Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Envoy=E9 : mardi 26 janvier 2010 10:20 > > =C0 : CHATRAS Bruno RD-CORE-ISS; adam@nostrum.com > > Cc : martini@ietf.org > > Objet : RE: [martini] Enumerating AORs/contacts > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: bruno.chatras@orange-ftgroup.com=20 > > > [mailto:bruno.chatras@orange-ftgroup.com] > > > Sent: 26 January 2010 08:29 > > > To: Elwell, John; adam@nostrum.com > > > Cc: martini@ietf.org > > > Subject: RE: [martini] Enumerating AORs/contacts > > >=20 > > > =20 > > >=20 > > > > -----Message d'origine----- > > > > De : martini-bounces@ietf.org > > > > [mailto:martini-bounces@ietf.org] De la part de Elwell,=20 > > John Envoy=E9=20 > > > > : mardi 26 janvier 2010 09:16 =C0 : Adam Roach Cc :=20 > > martini@ietf.org=20 > > > > Objet : [martini] Enumerating AORs/contacts > > > >=20 > > > > Changing the thread name to focus on another issue. > > > >=20 > > > > We seem to have converged on what Adam calls contact=20 > > routing, which=20 > > > > basically says that the domain part of the Request-URI in=20 > > an inbound=20 > > > > request should contain the domain part of the=20 > registered contact=20 > > > > URI, leaving the user part to identify the particular=20 > > AOR. I think=20 > > > > this does indeed correspond to one of the practices seen=20 > > in the wild=20 > > > > at present. > > > =3D=3D>BC: Hum, I still think that both the user part and the=20 > > domain part=20 > > > should be left unmodified. What are the concrete benefits=20 > > for the PBX=20 > > > if only the user part is left unchanged? > > [JRE] For reasons that Adam has given - sending a request to=20 > > sip:+12345@sp.com to pbx.com will result in looping back to=20 > > sp.com, since pbx.com is not responsible for that domain. >=20 > =3D=3D>BC: I was referring to a URI of the form=20 > user@enterprise.com, not user@sp.com [JRE] See Spencer's reply. >=20 > >=20 > > > >=20 > > > > This then leaves the question of whether we need to enumerate=20 > > > > the different user parts (and hence the AORs and their=20 > > > > respective contacts), either in the request (PBX to SP) or in=20 > > > > the response (SP to PBX). My question is whether we need this=20 > > > > at all - the question whether it should be in the request or=20 > > > > the response can be addressed after we have determined=20 > > > > whether it is needed at all. > > > =3D=3D>BC: I have no strong feeling as to whether we need it on=20 > > > the interface between the pBX and the SSP's edge proxy but I=20 > > > believe we do need it in the response from the Registrar to=20 > > > the SSP's edge proxy. > > [JRE] Can we somehow capture a requirement on this? Just=20 > > saying it needs to be conveyed to the edge proxy is not=20 > > sufficient. We need to identify a problem and capture a=20 > > requirement that avoids that problem. >=20 > =3D=3D>BC: The mechanism shall ensure that an SSP's edge proxy=20 > that is responsible for asserting identities as per RFC 3325=20 > is made aware of the list of identities implictly registered=20 > in the registrar. [JRE] I need advice how to include this - whether that interface is within = scope of MARTINI. John = From BLINDSAY@nortel.com Tue Jan 26 07:48:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354BC3A683F for ; Tue, 26 Jan 2010 07:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, 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 VGkdkWE2ZsJS for ; Tue, 26 Jan 2010 07:48:42 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F20EF3A6823 for ; Tue, 26 Jan 2010 07:48:41 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0QFmi515137; Tue, 26 Jan 2010 15:48:44 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 10:48:26 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C40F1FF@zcarhxm1.corp.nortel.com> In-Reply-To: <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkgAADKxIAAAEjFIAAAKrtA References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> From: "Brian Lindsay" To: , , Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:48:43 -0000 Hi, I think that's fine. We just don't need to bring the requirement into = the Martini draft. Such systems may have incremental requirements = above/beyond Martini. -----Original Message----- From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Tuesday, January 26, 2010 10:45 AM To: HKaplan@acmepacket.com; Lindsay, Brian (CAR:AR00); martini@ietf.org Subject: RE: [martini] Listing the implicitly registered AoR's I assume that IMS-based networks would continue to use P-Associated-URI = in their "closed" environnements rather than use an extended reg-event = package. I'v not seen any proposal to deprecate RFC3455 anyway... > -----Message d'origine----- > De : martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan = Envoy=E9=20 > : mardi 26 janvier 2010 16:34 =C0 : Brian Lindsay; martini@ietf.org=20 > Objet : Re: [martini] Listing the implicitly registered AoR's >=20 >=20 > Hi Brian, > I _think_ that's consistent with using reg-event, because we wouldn't=20 > document a requirement to use reg-event, just note that it could be=20 > used for that purpose (if even that). >=20 > -hadriel >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Brian Lindsay > > Sent: Tuesday, January 26, 2010 10:15 AM > > To: Hadriel Kaplan; martini@ietf.org > > Subject: Re: [martini] Listing the implicitly registered AoR's > >=20 > > Hi Hadriel, > >=20 > > I don't think this needs to be spelled out in the draft.=20 > There may > > be specific solutions/architectures like IMS that would use > this, and > > that's OK, but I don't believe this is central to the=20 > > mechanism/interface in the draft. > >=20 > > Thanks > > Brian > >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of Hadriel Kaplan > > Sent: Tuesday, January 26, 2010 10:02 AM > > To: martini@ietf.org > > Subject: [martini] Listing the implicitly registered AoR's > >=20 > > On the topic of listing implicitly registered AoR's (what has been=20 > > done so far in P-Associated-URI), the emails on this seem > to focus on > > either requiring it, or not at all. But there was a third option=20 > > proposed by someone on the last virtual meeting call: use > reg-event for that. > >=20 > > In other words, don't put them in a PAU/whatever of the REGISTER (or > > PUBLISH) request or response. Instead, use the subscription for=20 > > reg-event to list them. In the P-CSCF/edge-proxy case, the > edge-proxy > > itself can subscribe to that package after the IP-PBX has > registered > > itself. > >=20 > > That seemed like a good compromise to me. (I preferred having it in=20 > > the REGISTER response, but we can't have everything :) > >=20 > > -hadriel > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and = intended solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, = changed or falsified. If you are not the intended addressee of this message, please cancel it = immediately and inform the sender. ******************************** From adam@nostrum.com Tue Jan 26 07:49:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 839283A683F for ; Tue, 26 Jan 2010 07:49: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=[AWL=-0.000, BAYES_00=-2.599, 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 35GAA0Hjdt8L for ; Tue, 26 Jan 2010 07:49:15 -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 E01F33A6823 for ; Tue, 26 Jan 2010 07:49:13 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QFnJDf022897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 09:49:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F0EFF.6010800@nostrum.com> Date: Tue, 26 Jan 2010 09:49:19 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B5F0C9B.1010908@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010007030107020706010706" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:49:18 -0000 This is a multi-part message in MIME format. --------------010007030107020706010706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So, in my previous examples, you're thinking that Braniff would want to be giving out r-uris of the form "sip:adam@centricvoice.com" instead of "sip:adam@braniff.com"? /a On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote: > > Sorry I should have been explicit about the context. The context was > the SSP receives a request for "sip:foobar@ssp.com". The SSP is > authoritative for ssp.com. It retargets to pbx.com. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* Tuesday, January 26, 2010 10:39 AM > *To:* martini@ietf.org > *Subject:* Re: [martini] The much maligned Request-URI > > On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: > > That's consistent with what *should* happen, because if the request wassip:foobar@ssp.com and was routed to pbx.com, then it got *retargeted*. Luckily (or not) retargeting rules are basically completely open in 3261. We can do whatever magic we want to. > > > > That's only true for a proxy that is responsible for the R-URI. > Everyone else is pretty tightly constrained in what they can do -- > basically, they can add Route headers, but they are forbidden from > retargeting. RFC 3261 has at least two normative statements on the topic: > > "A proxy MUST NOT add additional targets to the target set if the > Request-URI of the original request does not indicate a resource this > proxy is responsible for." > > "If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding" > > > > > There have been some threads that changing"sip:foobar@ssp.com" to"sip:foobar@pbx.com" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com. I think that's a red herring argument. In what way, shape or form could the SSP have possibly *blindly* retargetedfoobar@ssp.com tofoobar@pbx.com ?? Clearly the SSP must have had some retargeting entry for"foobar@ssp.com" - the whole thing, not just the host. > > > I agree. The prospect of ignoring the domain and treating the user as > a unique key is highly problematic. > > > So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP > > > The SSP can't retarget unless is responsible for the domain. > > But if the SSP is responsible for the domain, then the PBX can't > retarget the requests once they arrive, which means they can't send > them to the proper terminal. > > Which is why we need to nail down domain responsibility. > > /a > --------------010007030107020706010706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So, in my previous examples, you're thinking that Braniff would want to be giving out r-uris of the form "sip:adam@centricvoice.com" instead of "sip:adam@braniff.com"?

/a

On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote:

Sorry I should have been explicit about the context.  The context was the SSP receives a request for “sip:foobar@ssp.com”.  The SSP is authoritative for ssp.com.  It retargets to pbx.com.

 

-hadriel

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Tuesday, January 26, 2010 10:39 AM
To: martini@ietf.org
Subject: Re: [martini] The much maligned Request-URI

 

On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: 

That's consistent with what *should* happen, because if the request was sip:foobar@ssp.com and was routed to pbx.com, then it got *retargeted*.  Luckily (or not) retargeting rules are basically completely open in 3261.  We can do whatever magic we want to.
 


That's only true for a proxy that is responsible for the R-URI. Everyone else is pretty tightly constrained in what they can do -- basically, they can add Route headers, but they are forbidden from retargeting. RFC 3261 has at least two normative statements on the topic:

"A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding"



 
There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly* is broken for anything but E.164 because foobar may be someone different for pbx.com.  I think that's a red herring argument.  In what way, shape or form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com??  Clearly the SSP must have had some retargeting entry for "foobar@ssp.com" - the whole thing, not just the host.


I agree. The prospect of ignoring the domain and treating the user as a unique key is highly problematic.


So ISTM what we're really talking about is whether the PBX should be able to provision the retargeting rules themselves in the SSP


The SSP can't retarget unless is responsible for the domain.

But if the SSP is responsible for the domain, then the PBX can't retarget the requests once they arrive, which means they can't send them to the proper terminal.

Which is why we need to nail down domain responsibility.

/a


--------------010007030107020706010706-- From bernard_aboba@hotmail.com Tue Jan 26 07:50:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7C53A688D for ; Tue, 26 Jan 2010 07:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K2ni+5V-J075 for ; Tue, 26 Jan 2010 07:50:45 -0800 (PST) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by core3.amsl.com (Postfix) with ESMTP id A4DB13A68C7 for ; Tue, 26 Jan 2010 07:50:45 -0800 (PST) Received: from BLU137-DS4 ([65.55.111.72]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 07:50:56 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 26 Jan 2010 07:52:14 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0110_01CA9E5C.79F54F20" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqen4fVdysGd/RmRvmoC9C0BWEmsA== Content-Language: en-us X-OriginalArrivalTime: 26 Jan 2010 15:50:56.0004 (UTC) FILETIME=[58C90C40:01CA9E9F] Subject: [martini] MARTINI Virtual Interim II Agenda -- Take Three X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:50:47 -0000 ------=_NextPart_000_0110_01CA9E5C.79F54F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim II January 26, 2010 9 AM - 11 AM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg00232.html Agenda 9 AM - 9:10 AM PT: Preliminaries Conference issues/debugging Agenda bash Requirements (20 minutes) 9:10 AM - 9:30 AM PT MARTINI Requirements, John Elwell (20 minutes) Invited Talks (30 minutes) 9:30 AM - 9:40 AM PT MARTINI Issues, Dean Willis (10 minutes) 9:40 AM - 9:50 AM PT Implicit Registration in IMS, Keith Drage (10 minutes) 9:50 AM - 10:00 AM PT Service Provider Perspective, TBD (10 minutes) Issue Discussion (30 minutes) 10:00 AM - 10:30 AM PT Issue Discussion, Presenter: Adam Roach (30 minutes) Wrap-up (30 minutes) 10:30 AM - 10:40 AM PT Discussion: Participants (10 minutes) 10:40 AM - 10:55 AM PT Hums: WG Chairs (15 minutes) 10:55 AM - 11:00 AM PT Next Steps: WG Chairs & ADs (5 minutes) ------=_NextPart_000_0110_01CA9E5C.79F54F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim II

January 26, 2010

9 AM – 11 AM Pacific Time

 

Conferencing Details:

 

Slide Presentations:  http://www.drizzle.com/~aboba/MARTINI/Jan-Interim-II/

Jabber room:  martini at jabber.ietf.org = (Please join)

Dial in Audioconference and WebEx = details:   http://www.ietf.org/mail-archive/web/martini/current/msg00232.html

 

Agenda

 

9 AM - 9:10 AM PT:  = Preliminaries

     Conference = issues/debugging

     Agenda bash

 

Requirements (20 minutes)

 

9:10 AM – 9:30 AM  PT MARTINI = Requirements, John Elwell (20 minutes)

 

Invited Talks (30 minutes)

 

9:30 AM – 9:40 AM PT  MARTINI Issues, = Dean Willis (10 minutes)

 

9:40 AM – 9:50 AM PT  Implicit = Registration in IMS, Keith Drage (10 minutes)

 

9:50 AM – 10:00 AM PT  Service Provider = Perspective, TBD (10 minutes)

 

Issue Discussion (30 minutes)

 

10:00 AM – 10:30  AM PT Issue = Discussion, Presenter: Adam Roach (30 minutes)

 

Wrap-up (30 minutes)

 

10:30 AM - 10:40 AM PT  Discussion:  = Participants (10 minutes)

10:40 AM - 10:55 AM PT  Hums:  WG Chairs = (15 minutes)

10:55 AM – 11:00 AM PT   Next = Steps:  WG Chairs & ADs (5 minutes)

------=_NextPart_000_0110_01CA9E5C.79F54F20-- From dean.willis@softarmor.com Tue Jan 26 07:52:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D9A3A6828 for ; Tue, 26 Jan 2010 07:52:04 -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 42yGgLarmiAS for ; Tue, 26 Jan 2010 07:52:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0338F3A6876 for ; Tue, 26 Jan 2010 07:52:03 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QFqCNA017010 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:52:14 -0600 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 09:52:07 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:52:04 -0000 On Jan 26, 2010, at 2:16 AM, Elwell, John wrote: > Changing the thread name to focus on another issue. > > We seem to have converged on what Adam calls contact routing, which > basically says that the domain part of the Request-URI in an inbound > request should contain the domain part of the registered contact > URI, leaving the user part to identify the particular AOR. I think > this does indeed correspond to one of the practices seen in the wild > at present. > That's not contact-routing, and I don't THINK it's what Adam means. I think Adam means that there MUST be a unique contact URI for each AOR, One possible way for making this happen is to have at least one unique registered contact per AOR (that's traditional contact-routing on registrations, as done in RFC 3261) Another is to have one registered contact "domain part" per AOR "domain part", and preserve user-parts across the transformation. I believe this is what Adam is proposing. > This then leaves the question of whether we need to enumerate the > different user parts (and hence the AORs and their respective > contacts), either in the request (PBX to SP) or in the response (SP > to PBX). My question is whether we need this at all - the question > whether it should be in the request or the response can be addressed > after we have determined whether it is needed at all. > > The argument for exchanging this information is to ensure that the > two sides are aligned, or at least to detect if there is > misalignment. It is probably not a mechanism for making changes to > the set of user parts - my opinion is that that is a provisioning > issue and outside the scope of MARTINI. I believe the intent is that, using Adam's proposal, the SSP requires no prior knowledge of the set of user-parts,. As PBX adds users, there is no "provisioning change" to the SSP. Possibly new registration messages, but no hard-state changes. -- Dean From HKaplan@acmepacket.com Tue Jan 26 07:52:16 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356553A6876 for ; Tue, 26 Jan 2010 07:52: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 q9dfrgOxPvAN for ; Tue, 26 Jan 2010 07:52:15 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 91D0F3A6828 for ; Tue, 26 Jan 2010 07:52:11 -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; Tue, 26 Jan 2010 10:52:21 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 10:52:21 -0500 From: Hadriel Kaplan To: "bruno.chatras@orange-ftgroup.com" , "martini@ietf.org" Date: Tue, 26 Jan 2010 10:52:20 -0500 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqenMYLL2zn1Yg1TNO+1bnkx+ZXMQAAMdwwAABJBlA= Message-ID: References: <4787_1264520380_4B5F0CBC_4787_2770_1_9ECCF01B52E7AB408A7EB85352642141010535B4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4787_1264520380_4B5F0CBC_4787_2770_1_9ECCF01B52E7AB408A7EB85352642141010535B4@ftrdmel0.rd.francetelecom.fr> 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: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:52:16 -0000 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com [mailto:bruno.chatras@orange- > ftgroup.com] > Sent: Tuesday, January 26, 2010 10:40 AM >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan > > Envoy=E9 : mardi 26 janvier 2010 16:33 > > I don't think Option-1 is a real option. As far as I know, > > in virtually all cases of IP-PBX trunking I've been involved > > with, by the time the request gets to the IP-PBX, the > > req-uri's domain/host portion identifies the IP-PBX's domain > > or host/IP. It may not be the routing proxy-registrar which > > does it, but a middlebox instead... but it will get changed > > if it wasn't already right. > > >=20 > =3D=3D>BC: This statement sounds strange to me as I have seen cases where= the > middlebox does the opposite: overrides the Request-URI with the contents > of a P-Called-Party-Id header field so as to restore the initial value > Request-URI. Huh. I've seen us do that - but for the user portion only. (because the or= iginal req-uri was replaced by the registrar-proxy to be the registered con= tact-uri and lost the actual target info) For the cases you've seen where the req-uri ended up being the SSP's domain= again when it reached the IP-PBX, was the IP-PBX actually provisioned to b= e in the SSP's domain? I have seen that - the IP-PBX was configured to lit= erally be in ssp.com, with a default route for unknown users to the "real" = SSP proxies. -hadriel From bruno.chatras@orange-ftgroup.com Tue Jan 26 07:53:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973B73A6828 for ; Tue, 26 Jan 2010 07:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 6n-6vuvUNrZV for ; Tue, 26 Jan 2010 07:53:16 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 5978F3A67C0 for ; Tue, 26 Jan 2010 07:53:16 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 6AC7137448F; Tue, 26 Jan 2010 16:53:26 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 528D6C804B; Tue, 26 Jan 2010 16:53:26 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:53:26 +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, 26 Jan 2010 16:53:24 +0100 Message-ID: <12909_1264521206_4B5F0FF6_12909_64141_1_9ECCF01B52E7AB408A7EB85352642141010535FE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C40F1FF@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkgAADKxIAAAEjFIAAAKrtAAAAsEbA= References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C40F1FF@zcarhxm1.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 26 Jan 2010 15:53:26.0388 (UTC) FILETIME=[B26BD340:01CA9E9F] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.153328 Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:53:17 -0000 Then we could ask whether there are other SIP-based architectures that woul= d require the list of implictly registered identities to be conveyed from t= he registrar to the edge proxy. If the answer if no and the use of P-Associ= ated-URI is not deprecated in IMS-based networks, I'm not sure it's worth e= xtending the reg-event event package. > -----Message d'origine----- > De : Brian Lindsay [mailto:blindsay@nortel.com]=20 > Envoy=E9 : mardi 26 janvier 2010 16:48 > =C0 : CHATRAS Bruno RD-CORE-ISS; HKaplan@acmepacket.com;=20 > martini@ietf.org > Objet : RE: [martini] Listing the implicitly registered AoR's >=20 > Hi, >=20 > I think that's fine. We just don't need to bring the=20 > requirement into the Martini draft. Such systems may have=20 > incremental requirements above/beyond Martini. >=20 > -----Original Message----- > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-ftgroup.com] > Sent: Tuesday, January 26, 2010 10:45 AM > To: HKaplan@acmepacket.com; Lindsay, Brian (CAR:AR00);=20 > martini@ietf.org > Subject: RE: [martini] Listing the implicitly registered AoR's >=20 > I assume that IMS-based networks would continue to use=20 > P-Associated-URI in their "closed" environnements rather than=20 > use an extended reg-event package. I'v not seen any proposal=20 > to deprecate RFC3455 anyway... >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Hadriel=20 > Kaplan Envoy=E9 > > : mardi 26 janvier 2010 16:34 =C0 : Brian Lindsay; martini@ietf.org=20 > > Objet : Re: [martini] Listing the implicitly registered AoR's > >=20 > >=20 > > Hi Brian, > > I _think_ that's consistent with using reg-event, because=20 > we wouldn't=20 > > document a requirement to use reg-event, just note that it could be=20 > > used for that purpose (if even that). > >=20 > > -hadriel > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > > > Behalf Of Brian Lindsay > > > Sent: Tuesday, January 26, 2010 10:15 AM > > > To: Hadriel Kaplan; martini@ietf.org > > > Subject: Re: [martini] Listing the implicitly registered AoR's > > >=20 > > > Hi Hadriel, > > >=20 > > > I don't think this needs to be spelled out in the draft.=20 > > There may > > > be specific solutions/architectures like IMS that would use > > this, and > > > that's OK, but I don't believe this is central to the=20 > > > mechanism/interface in the draft. > > >=20 > > > Thanks > > > Brian > > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > > > Behalf Of Hadriel Kaplan > > > Sent: Tuesday, January 26, 2010 10:02 AM > > > To: martini@ietf.org > > > Subject: [martini] Listing the implicitly registered AoR's > > >=20 > > > On the topic of listing implicitly registered AoR's (what=20 > has been=20 > > > done so far in P-Associated-URI), the emails on this seem > > to focus on > > > either requiring it, or not at all. But there was a third option=20 > > > proposed by someone on the last virtual meeting call: use > > reg-event for that. > > >=20 > > > In other words, don't put them in a PAU/whatever of the=20 > REGISTER (or > > > PUBLISH) request or response. Instead, use the subscription for=20 > > > reg-event to list them. In the P-CSCF/edge-proxy case, the > > edge-proxy > > > itself can subscribe to that package after the IP-PBX has > > registered > > > itself. > > >=20 > > > That seemed like a good compromise to me. (I preferred=20 > having it in=20 > > > the REGISTER response, but we can't have everything :) > > >=20 > > > -hadriel > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From dean.willis@softarmor.com Tue Jan 26 07:55:06 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575D83A688C for ; Tue, 26 Jan 2010 07:55:06 -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 U4zmRAvMIm2o for ; Tue, 26 Jan 2010 07:55:05 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 874843A6876 for ; Tue, 26 Jan 2010 07:55:05 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QFtEx0017062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 09:55:15 -0600 Message-Id: <937FFF37-CF39-4A0B-8D47-BB45921BAE6F@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B5EF7D7.3030305@nostrum.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: Tue, 26 Jan 2010 09:55:09 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> <4B5EF7D7.3030305@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:55:06 -0000 On Jan 26, 2010, at 8:10 AM, Adam Roach wrote: > On 1/26/10 02:16, Jan 26, Elwell, John wrote: >> Changing the thread name to focus on another issue. >> >> We seem to have converged on what Adam calls contact routing, which >> basically says that the domain part of the Request-URI in an >> inbound request should contain the domain part of the registered >> contact URI, leaving the user part to identify the particular AOR. > > So, that's not *quite* right. The right-hand-side corresponds to the > PBX. In the dynamic-IP scenario, it ends up being the PBX's IP > address, not a domain it claims responsibility for. And in that scenario, if the PBX supports two domains, and those domains have separate user-name spaces, then the PBX needs to have two dynamic addresses. Or three addresses for three domains, etc. -- Dean From adam@nostrum.com Tue Jan 26 07:57:27 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725453A6876 for ; Tue, 26 Jan 2010 07:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Ybuq+V1udc0b for ; Tue, 26 Jan 2010 07:57:26 -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 370A53A683F for ; Tue, 26 Jan 2010 07:57:25 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QFvYga023577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 09:57:34 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F10EE.9060709@nostrum.com> Date: Tue, 26 Jan 2010 09:57:34 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> <4B5EF7D7.3030305@nostrum.com> <937FFF37-CF39-4A0B-8D47-BB45921BAE6F@softarmor.com> In-Reply-To: <937FFF37-CF39-4A0B-8D47-BB45921BAE6F@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:57:27 -0000 On 1/26/10 09:55, Jan 26, Dean Willis wrote: > > On Jan 26, 2010, at 8:10 AM, Adam Roach wrote: > >> On 1/26/10 02:16, Jan 26, Elwell, John wrote: >>> Changing the thread name to focus on another issue. >>> >>> We seem to have converged on what Adam calls contact routing, which >>> basically says that the domain part of the Request-URI in an inbound >>> request should contain the domain part of the registered contact >>> URI, leaving the user part to identify the particular AOR. >> >> So, that's not *quite* right. The right-hand-side corresponds to the >> PBX. In the dynamic-IP scenario, it ends up being the PBX's IP >> address, not a domain it claims responsibility for. > > And in that scenario, if the PBX supports two domains, and those > domains have separate user-name spaces, then the PBX needs to have > two dynamic addresses. Or three addresses for three domains, etc. Or rules to rewrite each AOR into a unique contact address, each of which has that same IP address as the right-hand-side. I've given examples of how this works several times. /a From bruno.chatras@orange-ftgroup.com Tue Jan 26 07:58:03 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8423A67B6 for ; Tue, 26 Jan 2010 07:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 waHvY+nemtq2 for ; Tue, 26 Jan 2010 07:58:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id DC0AC3A6774 for ; Tue, 26 Jan 2010 07:58:01 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 070D3324198; Tue, 26 Jan 2010 16:58:11 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E1BDC27C054; Tue, 26 Jan 2010 16:58:10 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 16:58:10 +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, 26 Jan 2010 16:58:09 +0100 Message-ID: <18501_1264521490_4B5F1112_18501_125_1_9ECCF01B52E7AB408A7EB853526421410105361A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqenMYLL2zn1Yg1TNO+1bnkx+ZXMQAAMdwwAABJBlAAAFVlIA== References: <4787_1264520380_4B5F0CBC_4787_2770_1_9ECCF01B52E7AB408A7EB85352642141010535B4@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 26 Jan 2010 15:58:10.0505 (UTC) FILETIME=[5BC4A390:01CA9EA0] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.13.111532 Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:58:03 -0000 =20 > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : mardi 26 janvier 2010 16:52 > =C0 : CHATRAS Bruno RD-CORE-ISS; martini@ietf.org > Objet : RE: [martini] The much maligned Request-URI >=20 >=20 >=20 > > -----Original Message----- > > From: bruno.chatras@orange-ftgroup.com=20 > [mailto:bruno.chatras@orange-=20 > > ftgroup.com] > > Sent: Tuesday, January 26, 2010 10:40 AM > >=20 > > > -----Message d'origine----- > > > De : martini-bounces@ietf.org > > > [mailto:martini-bounces@ietf.org] De la part de Hadriel Kaplan=20 > > > Envoy=E9 : mardi 26 janvier 2010 16:33 I don't think Option-1 is a=20 > > > real option. As far as I know, in virtually all cases of IP-PBX=20 > > > trunking I've been involved with, by the time the request gets to=20 > > > the IP-PBX, the req-uri's domain/host portion identifies the=20 > > > IP-PBX's domain or host/IP. It may not be the routing=20 > > > proxy-registrar which does it, but a middlebox instead... but it=20 > > > will get changed if it wasn't already right. > > > > >=20 > > =3D=3D>BC: This statement sounds strange to me as I have seen=20 > cases where=20 > > the middlebox does the opposite: overrides the Request-URI with the=20 > > contents of a P-Called-Party-Id header field so as to restore the=20 > > initial value Request-URI. >=20 > Huh. I've seen us do that - but for the user portion only.=20 > (because the original req-uri was replaced by the=20 > registrar-proxy to be the registered contact-uri and lost the=20 > actual target info) >=20 > For the cases you've seen where the req-uri ended up being=20 > the SSP's domain again when it reached the IP-PBX, was the=20 > IP-PBX actually provisioned to be in the SSP's domain? I=20 > have seen that - the IP-PBX was configured to literally be in=20 > ssp.com, with a default route for unknown users to the "real"=20 > SSP proxies. =3D=3D>BC: I have to double check but from memory the edge proxy was replac= ing the R-URI with the contents of the P-Called-Pary-Id,irrespective of the= domain name. >=20 > -hadriel >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From john.elwell@siemens-enterprise.com Tue Jan 26 07:58:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719743A67EB for ; Tue, 26 Jan 2010 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ZAorlfg7iUh4 for ; Tue, 26 Jan 2010 07:58:43 -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 594873A67B6 for ; Tue, 26 Jan 2010 07:58:43 -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-672448; Tue, 26 Jan 2010 16:58:52 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 80D1923F02AA; Tue, 26 Jan 2010 16:58:52 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 26 Jan 2010 16:58:52 +0100 From: "Elwell, John" To: Dean Willis Date: Tue, 26 Jan 2010 16:58:51 +0100 Thread-Topic: [martini] Requirements - rev2 Thread-Index: AcqemQy1EOQC7usITfq7hfAwy0/HJAABnVAg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 15:58:44 -0000 =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 26 January 2010 15:06 > To: Elwell, John > Cc: Spencer Dawkins; martini@ietf.org > Subject: Re: [martini] Requirements - rev2 >=20 >=20 > On Jan 25, 2010, at 11:35 AM, Elwell, John wrote: >=20 > > Spencer, > > > > My feedback below. > > > >> -----Original Message----- > >> From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > >> Sent: 25 January 2010 16:42 > >> To: Elwell, John; martini@ietf.org > >> Subject: Re: [martini] Requirements - rev2 > >> > >> Hi, John, > >> > >> (As co-chair) Thanks for continuing to herd this along the path. > >> > >> (as individual) A couple of questions inline... > >> > >> > >>> - The mechanism MUST allow the PBX to be responsible for > >> its AORs and to > >>> handle requests to those AORs according to its rules. > >> > >> Are we crystal clear on what "responsible for its AORs" means? I am > >> remembering conversations that centered around where DNS > >> records pointed, > >> for instance. > > [JRE] Yes, I agree we need something more concrete. Any text =20 > > proposals from anyone? >=20 > How about: >=20 > Such that the PBX or its operators have a trusted signing=20 > certificate =20 > (CA) for the domain, and can use that certificate to sign a shorter-=20 > lived certificate that will be delegated to SSP allowing the SSP to, =20 > for a limited duration, appear to be authoritative for that domain =20 > when contacted using the procedures of RFC 3263 and SIPS. [JRE] It seems to me this might be getting a bit beyond requirements and in= to mechanism. I can understand that a PBX responsible for a domain should = be able to obtain a certificate from that domain from a well-known CA. The = need to have a CA cert, use that for minting other certs and using them as = you describe seems to be too much. John >=20 > Of course, we need a mechanism for pushing that cert from PBX to SSP. >=20 > We may also need to talk about service-dispatch. The SSP MUST NOT do =20 > per-user service dispatch using Service-Route, since all users =20 > registered with a single request get the same Service-Route. >=20 > -- > Dean >=20 >=20 >=20 > = From HKaplan@acmepacket.com Tue Jan 26 08:00:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB233A695A for ; Tue, 26 Jan 2010 08:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 DCvgmqQUBfH2 for ; Tue, 26 Jan 2010 08:00:50 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 88D763A6947 for ; Tue, 26 Jan 2010 08:00:49 -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; Tue, 26 Jan 2010 11:00:59 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 11:00:59 -0500 From: Hadriel Kaplan To: Adam Roach Date: Tue, 26 Jan 2010 11:00:58 -0500 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqenyL0eRey9kg+TpmTNlDjYJuksAAAM2HQ Message-ID: References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> In-Reply-To: <4B5F0EFF.6010800@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1BACmail_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:00:58 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1BACmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not at all - I have no idea what Braniff would want to do (probably use ada= m@verizon.com, since Verizon now owns Braniff's fo= rmer headquarters building :)). But seriously, how a request to adam@braniff.com h= appened to get to centricvoice's proxies does not matter, and is not in sco= pe. All we're doing is figuring out how a request to adam@braniff.com gets from centricvoice to braniff. hadriel ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, January 26, 2010 10:49 AM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI So, in my previous examples, you're thinking that Braniff would want to be = giving out r-uris of the form "sip:adam@centricvoice.com" instead of "sip:adam@braniff.com"? /a On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote: Sorry I should have been explicit about the context. The context was the S= SP receives a request for "sip:foobar@ssp.com". = The SSP is authoritative for ssp.com. It retargets to pbx.com. -hadriel ________________________________ From: martini-bounces@ietf.org [mailto:mar= tini-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, January 26, 2010 10:39 AM To: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: That's consistent with what *should* happen, because if the request was sip= :foobar@ssp.com and was routed to pbx.com, then = it got *retargeted*. Luckily (or not) retargeting rules are basically comp= letely open in 3261. We can do whatever magic we want to. That's only true for a proxy that is responsible for the R-URI. Everyone el= se is pretty tightly constrained in what they can do -- basically, they can= add Route headers, but they are forbidden from retargeting. RFC 3261 has a= t least two normative statements on the topic: "A proxy MUST NOT add additional targets to the target set if the Request-U= RI of the original request does not indicate a resource this proxy is respo= nsible for." "If the domain of the Request-URI indicates a domain this element is not re= sponsible for, the Request-URI MUST be placed into the target set as the on= ly target, and the element MUST proceed to the task of Request Forwarding" There have been some threads that changing "sip:foobar@ssp.com" to "sip:foobar@pbx.com" *blindly= * is broken for anything but E.164 because foobar may be someone different = for pbx.com. I think that's a red herring argument. In what way, shape or= form could the SSP have possibly *blindly* retargeted foobar@ssp.com to foobar@pbx.com?? Clearly the S= SP must have had some retargeting entry for "foobar@ssp.com" - the whole thing, not just the host. I agree. The prospect of ignoring the domain and treating the user as a uni= que key is highly problematic. So ISTM what we're really talking about is whether the PBX should be able t= o provision the retargeting rules themselves in the SSP The SSP can't retarget unless is responsible for the domain. But if the SSP is responsible for the domain, then the PBX can't retarget t= he requests once they arrive, which means they can't send them to the prope= r terminal. Which is why we need to nail down domain responsibility. /a --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1BACmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not at all – I have no idea what= Braniff would want to do (probably use adam@ver= izon.com, since Verizon now owns Braniff’s former headquarters building = J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter, and is not in scope.  Al= l we’re doing is figuring out how a request to adam@b= raniff.com gets from centricvoice to braniff.

hadriel

 

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2= 010 10:49 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= So, in my previous examples, you're thinking tha= t Braniff would want to be giving out r-uris of the form "sip:adam@centricvoice.com&q= uot; instead of "sip:adam@braniff.c= om"?

/a

On 1/26/10 09:44, Jan 26, Hadriel Kaplan wrote:

Sorry I should have been explicit about the context.  The context was the SSP receives a request for “sip:foobar@ssp.com”.  The= SSP is authoritative for ssp.com.  It retargets to pbx.com.

 =

-hadriel

 =

From: martini-boun= ces@ietf.org [mailto:martini-bounces@ietf.or= g] On Behalf Of Adam Roach
Sent: Tuesday, January 26, 2= 010 10:39 AM
To: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= On 1/26/10 09:32, Jan 26, Hadriel Kaplan wrote: <= /u1:p>

That's consistent with what *should* happen, bec=
ause if the request was sip:foobar@ssp.co=
m and was routed to pbx.com, then it got *retargeted*.  Luckily (o=
r not) retargeting rules are basically completely open in 3261.  We ca=
n do whatever magic we want to.
= 
 

=
That's only true for a proxy that is responsible for the R-URI. Everyone el= se is pretty tightly constrained in what they can do -- basically, they can ad= d Route headers, but they are forbidden from retargeting. RFC 3261 has at lea= st two normative statements on the topic:

"A proxy MUST NOT add additional targets to the ta= rget set if the Request-URI of the original request does not indicate a resource this proxy is responsible for."

"If the domain of the Request-URI indicates a domain this element is n= ot responsible for, the Request-URI MUST be placed into the target set as the = only target, and the element MUST proceed to the task of Request Forwarding"= ;




 
There have been some threads that changing "sip:foobar@=
ssp.com" to "sip:foobar@=
pbx.com" *blindly* is broken for anything but E.164 because foobar=
 may be someone different for pbx.com.  I think that's a red herring a=
rgument.  In what way, shape or form could the SSP have possibly *blin=
dly* retargeted foobar@ssp.com to=
 foobar@pbx.com??&=
nbsp; Clearly the SSP must have had some retargeting entry for "foobar@ssp.com&=
quot; - the whole thing, not just the host.



=


I agree. The prospect of ignoring the domain and treating the user as a uni=
que
key is highly problematic.











So ISTM what we're really talking about is wheth=
er the PBX should be able to provision the retargeting rules themselves in =
the SSP



=


The SSP can't retarget unless is responsible for the domain.



But if the SSP is responsible for the domain, then the PBX can't retarget t=
he
requests once they arrive, which means they can't send them to the proper
terminal.



Which is why we need to nail down domain responsibility.



/a

=  

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1BACmail_-- From fluffy@cisco.com Tue Jan 26 08:03:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F79528C0CF for ; Tue, 26 Jan 2010 08:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.274 X-Spam-Level: X-Spam-Status: No, score=-110.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmBOxcrXm3zg for ; Tue, 26 Jan 2010 08:03:46 -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 8EC843A6828 for ; Tue, 26 Jan 2010 08:03:46 -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: ApoEAD+hXkurR7H+/2dsb2JhbADCYpcThDkE X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="209411184" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2010 16:03:57 +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 o0QG3WFW024500; Tue, 26 Jan 2010 16:03:56 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 26 Jan 2010 09:03:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Elwell, John" X-Mailer: Apple Mail (2.1077) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:03:47 -0000 On Jan 8, 2010, at 10:46 AM, Elwell, John wrote: > - The mechanism MUST allow the PBX to be responsible for its AORs and = to handle requests to those AORs according to its rules. Is it OK for the SSP to send the call to voicemail? I'm not arguing one = way or the other here, I'm just trying to figure out if the SSP or PBX = is responsible for the AOR? From adam@nostrum.com Tue Jan 26 08:05:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053123A688E for ; Tue, 26 Jan 2010 08:05:05 -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, 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 I-YJwAty3lHE for ; Tue, 26 Jan 2010 08:05:00 -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 4B8053A6774 for ; Tue, 26 Jan 2010 08:05:00 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QG57Kn024257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 10:05:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F12B3.5020701@nostrum.com> Date: Tue, 26 Jan 2010 10:05:07 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060806080704040009040403" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:05:05 -0000 This is a multi-part message in MIME format. --------------060806080704040009040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: > > Not at all -- I have no idea what Braniff would want to do (probably > use adam@verizon.com , since Verizon now owns > Braniff's former headquarters building J). > > But seriously, how a request to adam@braniff.com > happened to get to centricvoice's proxies > does not matter... > It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude. The answer to that question must be "it works AT LEAST for the cases in which RFC 3263 routing procedures took it to the SSP". If you want to make it work for other scenarios, that's fine. But if you're designing a solution that cannot work on the Internet at large, then it really won't fly. /a --------------060806080704040009040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:

Not at all – I have no idea what Braniff would want to do (probably use adam@verizon.com, since Verizon now owns Braniff’s former headquarters building J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter...


It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases in which RFC 3263 routing procedures took it to the SSP". If you want to make it work for other scenarios, that's fine. But if you're designing a solution that cannot work on the Internet at large, then it really won't fly.

/a
--------------060806080704040009040403-- From spencer@wonderhamster.org Tue Jan 26 08:12:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B3328C0CF for ; Tue, 26 Jan 2010 08:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 fhGgvzAVcDxo for ; Tue, 26 Jan 2010 08:12:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id D67A73A68AF for ; Tue, 26 Jan 2010 08:12:44 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1NZo203uc4-000Qol; Tue, 26 Jan 2010 11:12:51 -0500 Message-ID: From: "Spencer Dawkins" To: "Hadriel Kaplan" , , , References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> Date: Tue, 26 Jan 2010 10:12:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX180UaR42Lfuc6t4xvJeHs+ZFa7m9E/MpNaR2yd D8LHasaElgqA1AJwrmr6VWPFGn+M/60k5cvjhn1bunARzprsJf Ca8RlcQ2rNAXcfEAuU5fR7TVcj6G03vDDyLG5fqwG4= Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:12:50 -0000 Hi, Hadriel, Sorry for being imprecise. "unless the service provider dorks with two-faced DNS" - that's the "we" I meant. And I'm not suggesting that service providers dork with two-faced DNS - just that it's one of the alternatives I can imagine someone implementing quickly as a shortcut. Thanks, Spencer ------------------------ > The problem with user@enterprise.com is that requests from outside the > service provider to this AOR would go straight to the SIP-PBX without > traversing any service provider proxy - unless we dork with two-faced DNS, > etc. *We* (martini) won't be dorking with anything. How a request got to the SSP is effectively out of scope for this WG, right? For all I know, the request originated in the SSP. The question isn't how it got to the SSP - the question is what the SSP should do about it once it gets it. :) -hadriel From spencer@wonderhamster.org Tue Jan 26 08:15:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FDE3A681B for ; Tue, 26 Jan 2010 08:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 6cHDX4SM1NUt for ; Tue, 26 Jan 2010 08:15:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E7F373A67D9 for ; Tue, 26 Jan 2010 08:15:43 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MMC6n-1NRonG3dEr-0089jL; Tue, 26 Jan 2010 11:15:52 -0500 Message-ID: <2B01EDFDE24C413AB77FBCD271E774F9@china.huawei.com> From: "Spencer Dawkins" To: "Bernard Aboba" , References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> Date: Tue, 26 Jan 2010 10:15:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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/JYXsaZRwRfY3sow6BAdWtoUQXRAuqFSPVqkc 7XZO4NPutPN9w9kpQnIVji2MMaAnbBAAL2z9apCb2/jydKyNIi xP+hW65SoEUaDdvhjU0BdfPmIR4D95TkmMD5+WLr4A= Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:15:46 -0000 Hi, Bernard, > Spencer said: > > "The problem with user@enterprise.com is that requests from outside the > service provider to this AOR would go straight to the SIP-PBX without > traversing any service provider proxy - unless we dork with two-faced DNS, > etc." > > [BA] Doesn't this depend on whether the DNS SRV RRs for "enterprise.com" > point to the service provider? If so, then shouldn't requests go to the > SP, > even if the A/AAAA RRs are dynamically updated to point to the SIP-PBX? Well, yes. I'm sorry I didn't say that more clearly, but your question points to the right answer. So the next question is "now that the request has arrived at the service provider based on DNS entries for enterprise.com pointing to the service provider, how would the request be sent to the SIP-PBX and processed by the SIP-PBX instead of being looped back to the servicer provider, if the request URI still contains a domain name that resolves to the service provider?" I'm sorry, I'm not following your mention about A/AAAA being dynamically updated to point to the SIP-PBX - when are you thinking this would happen? (during request handling? both before and after seem problematic. But maybe I'm missing something). Thanks, Spencer From richard@shockey.us Tue Jan 26 08:23:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE643A6868 for ; Tue, 26 Jan 2010 08:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 u9kg7q5Sy2Ac for ; Tue, 26 Jan 2010 08:23:04 -0800 (PST) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 1C1283A6869 for ; Tue, 26 Jan 2010 08:23:04 -0800 (PST) Received: (qmail 18998 invoked by uid 0); 26 Jan 2010 16:23:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy5.bluehost.com with SMTP; 26 Jan 2010 16:23:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-Identified-User; b=cxbCPQ59RIBfXnVxawMIe0IDUB4Cvdz7jZMbmqlvqGrPsG/X6V28zFyB7aoqQA0P65+LxocVCkGGXUKULG94LC7vXDlGKGQRpz4AP85STsRuso1iMzn1RfH96k3465bi; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NZoC9-0006l9-16 for martini@ietf.org; Tue, 26 Jan 2010 09:23:13 -0700 Message-ID: <4B5F16EF.1070301@shockey.us> Date: Tue, 26 Jan 2010 11:23:11 -0500 From: Richard Shockey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020405070600040604090506" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [martini] Request for Slides -- Take Two X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:23:10 -0000 This is a multi-part message in MIME format. --------------020405070600040604090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The other is proxy require .. On 1/26/2010 9:53 AM, Hadriel Kaplan wrote: > > I suggest we change the format of this meeting. Currently you have > Adam and I scheduled to deliver presentations on our drafts, but > nothing's changed with them afaik. The email discussion so far has > not really been specific to the drafts -- most of the topics have been > applicable no matter which draft model is used. > > So I suggest we just go through John's requirements and then discuss > the email topics, and skip the drafts. > > It appears the topics have been: > > 1) What to do with the req-uri: leave alone, contact-routing, or > re-targeting. > > 2) Which entity "owns" or is responsible for the Enterprise domain. > > 3) Whether to encode the implicitly registered AoR's in the > REGISTER/PUBLISH transaction, or not. > > Oddly the one topic I thought would be the hot one from the last > meeting, namely GRUU, has not been discussed on the mailing list afaict. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] *On > Behalf Of *Bernard Aboba > *Sent:* Monday, January 25, 2010 11:12 PM > *To:* martini@ietf.org > *Subject:* [martini] Request for Slides -- Take Two > > Given the complexities of some of the issues we've been talking about > on the list, the chances for a productive discussion will probably be > significantly be enhanced by use of slides during MARTINI Virtual > Interim II tomorrow. > > So if you are on the agenda for MARTINI Virtual Interim II, please > get your slides in to me and/or Spencer ASAP. > > I will be up early tomorrow so as to be able to get any received > slides up on the archive prior to the meeting.... but I'd prefer not > to have to scramble to get everything uploaded just before the meeting > (or during or after it). > > Thanks in advance! > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > -- Richard Shockey Shockey Consulting Chairman of Board SIP Forum Voice +1 703 593 2683 Skype etc : rshockey101 --------------020405070600040604090506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The other is proxy require ..  

On 1/26/2010 9:53 AM, Hadriel Kaplan wrote:

I suggest we change the format of this meeting.  Currently you have Adam and I scheduled to deliver presentations on our drafts, but nothing’s changed with them afaik.  The email discussion so far has not really been specific to the drafts – most of the topics have been applicable no matter which draft model is used.

So I suggest we just go through John’s requirements and then discuss the email topics, and skip the drafts.

 

It appears the topics have been:

1)       What to do with the req-uri: leave alone, contact-routing, or re-targeting.

2)       Which entity “owns” or is responsible for the Enterprise domain.

3)       Whether to encode the implicitly registered AoR’s in the REGISTER/PUBLISH transaction, or not.

 

Oddly the one topic I thought would be the hot one from the last meeting, namely GRUU, has not been discussed on the mailing list afaict.

 

-hadriel

 

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, January 25, 2010 11:12 PM
To: martini@ietf.org
Subject: [martini] Request for Slides -- Take Two

 

Given the complexities of some of the issues we’ve been talking about on the list, the chances for a productive discussion will probably be significantly be enhanced by use of slides during MARTINI Virtual Interim II tomorrow.

 

So if you are on the agenda for MARTINI Virtual Interim II,  please get your slides in to me and/or Spencer ASAP.   

 

I will be up early tomorrow so as to be able to get any received slides up on the archive prior to the meeting…. but I’d prefer not to have to scramble to get everything uploaded just before the meeting (or during or after it).

 

Thanks in advance!

 


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

-- 
Richard Shockey
Shockey Consulting
Chairman of Board SIP Forum
Voice +1 703 593 2683
Skype etc : rshockey101
--------------020405070600040604090506-- From bruno.chatras@orange-ftgroup.com Tue Jan 26 08:26:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC6B3A68CD for ; Tue, 26 Jan 2010 08:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 LRB63xgmfvXd for ; Tue, 26 Jan 2010 08:26:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 773F028C0DB for ; Tue, 26 Jan 2010 08:26:35 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DAFD91B86E1; Tue, 26 Jan 2010 17:26:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id BB40E158045; Tue, 26 Jan 2010 17:26:45 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 17:26: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, 26 Jan 2010 17:26:44 +0100 Message-ID: <27429_1264523205_4B5F17C5_27429_213336_1_9ECCF01B52E7AB408A7EB85352642141010536A0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2B01EDFDE24C413AB77FBCD271E774F9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqeovp/lwU4BHvFQ3CptVwC4uE9tAAAQ1AA References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> <2B01EDFDE24C413AB77FBCD271E774F9@china.huawei.com> From: To: , X-OriginalArrivalTime: 26 Jan 2010 16:26:45.0849 (UTC) FILETIME=[5A315C90:01CA9EA4] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.160035 Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:26:36 -0000 =20 > -----Message d'origine----- > De : Spencer Dawkins [mailto:spencer@wonderhamster.org]=20 > Envoy=E9 : mardi 26 janvier 2010 17:16 > =C0 : Bernard Aboba; CHATRAS Bruno RD-CORE-ISS > Cc : martini@ietf.org > Objet : Re: [martini] Enumerating AORs/contacts >=20 > Hi, Bernard, >=20 > > Spencer said: > > > > "The problem with user@enterprise.com is that requests from outside=20 > > the service provider to this AOR would go straight to the SIP-PBX=20 > > without traversing any service provider proxy - unless we dork with=20 > > two-faced DNS, etc." > > > > [BA] Doesn't this depend on whether the DNS SRV RRs for=20 > "enterprise.com" > > point to the service provider? If so, then shouldn't=20 > requests go to=20 > > the SP, even if the A/AAAA RRs are dynamically updated to=20 > point to the=20 > > SIP-PBX? >=20 > Well, yes. I'm sorry I didn't say that more clearly, but your=20 > question points to the right answer. >=20 > So the next question is "now that the request has arrived at=20 > the service provider based on DNS entries for enterprise.com=20 > pointing to the service provider, how would the request be=20 > sent to the SIP-PBX and processed by the SIP-PBX instead of=20 > being looped back to the servicer provider, if the request=20 > URI still contains a domain name that resolves to the service=20 > provider?" =3D=3D>BC: The Location Service in the SSP will return a contact address re= presenting the PBX in response to a query from a proxy in the SSP domain. T= his proxy will include the contact address in the route header field and le= ave the R-URI unchanged. >=20 > I'm sorry, I'm not following your mention about A/AAAA being=20 > dynamically updated to point to the SIP-PBX - when are you=20 > thinking this would happen?=20 > (during request handling? both before and after seem=20 > problematic. But maybe I'm missing something). >=20 > Thanks, >=20 > Spencer >=20 >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From spencer@wonderhamster.org Tue Jan 26 08:30:39 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780DE3A6907 for ; Tue, 26 Jan 2010 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 hNChrDALxS+l for ; Tue, 26 Jan 2010 08:30:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 3EA073A688C for ; Tue, 26 Jan 2010 08:30:38 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LngZT-1O0bPh23F1-00hlyJ; Tue, 26 Jan 2010 11:30:47 -0500 Message-ID: <668491D980524BFAB8B4F918CBF92579@china.huawei.com> From: "Spencer Dawkins" To: "Sanjay Sinha \(sanjsinh\)" , "Christer Holmberg" , "Elwell, John" , References: <00FC4AA684E90E4DA2FF71021CD5A6CAA06899@XMB-RCD-101.cisco.com> Date: Tue, 26 Jan 2010 10:30:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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+WjMV7Oae8027P7ai5LJar83BhPX7S2m8LFY9 sm4OyNx3bxRk3kAWT6s/gTU6oVEfFurRKWX7HiM482Ogas87RR t3Jx+KvWepj8g7JTOubJ9CoHcgxFTgl0tlBI47GkaI= Subject: Re: [martini] Transport requirements X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:30:39 -0000 Hi, Sanjay, > Considering registration may be the long pole, if a transport > requirement works for register, it should work for other SIP > transactions also. > > Sanjay I understand what you're saying here. My concern is that we might pick a maximum number for this mechanism in general that accommodates UDP, even if there are people who are willing to use TCP since they worry about how big the requests and responses could be. Thanks, Spencer, as individual From richard@shockey.us Tue Jan 26 08:30:52 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEB23A694F for ; Tue, 26 Jan 2010 08:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_20=-0.74, 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 Dri5emDm4nMe for ; Tue, 26 Jan 2010 08:30:51 -0800 (PST) Received: from outbound-mail-111.bluehost.com (outbound-mail-111.bluehost.com [69.89.18.7]) by core3.amsl.com (Postfix) with SMTP id 0F09F3A6933 for ; Tue, 26 Jan 2010 08:30:51 -0800 (PST) Received: (qmail 4687 invoked by uid 0); 26 Jan 2010 16:31:00 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy3.bluehost.com with SMTP; 26 Jan 2010 16:31:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gr16AwZsCejbbh1e1mogUbmyghcNgU7dOUp7B705w1VxV72fbLZBAiRN/KCW13Hh0Mz9O6GEF3j2ilSLNsIgjaxQriELMAmaAyQHQHCk2uxqXsUPynGgUl3IOmBiABBm; Received: from pool-96-241-233-91.washdc.fios.verizon.net ([96.241.233.91] helo=[192.168.1.4]) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NZoJf-0002aX-B9 for martini@ietf.org; Tue, 26 Jan 2010 09:31:00 -0700 Message-ID: <4B5F18C2.1050305@shockey.us> Date: Tue, 26 Jan 2010 11:30:58 -0500 From: Richard Shockey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com> <778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> In-Reply-To: <778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.241.233.91 authed with richard+shockey.us} Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:30:52 -0000 Dean ...typically the business context for MARTINI is almost exclusively E.164 naming where the SSP is in direct ownership/control of the Layer 1 connection. And yes .. I need to respond to Paul on the issues with assuming block number routing. This will become increasingly relevant as LNP rolls out in the EC. On 1/26/2010 10:44 AM, Dean Willis wrote: > > On Jan 25, 2010, at 5:40 PM, Paul Kyzivat wrote: > >> Spencer, >> >> I guess this needs to be segmented into separate issues, which you >> have already more or less done: ... > > > Excellent summary. One additional issue: > > Are the user-part identifiers restricted to being only encoded E.164 > numbers? Or is a more general user-part syntax allowed? > > If we restrict ourselves to E.164 user-parts, then a lot of the > complexity evaporates. > > > This brings a related issue: Are we talking about sip: request URIs or > tel: request URIs? > > -- > Dean > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > -- Richard Shockey Shockey Consulting Chairman of Board SIP Forum Voice +1 703 593 2683 Skype etc : rshockey101 From HKaplan@acmepacket.com Tue Jan 26 08:33:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612113A67D9 for ; Tue, 26 Jan 2010 08:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 IjU7s0eywvQO for ; Tue, 26 Jan 2010 08:33:44 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E7E673A6876 for ; Tue, 26 Jan 2010 08:33:43 -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; Tue, 26 Jan 2010 11:33:49 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 11:33:49 -0500 From: Hadriel Kaplan To: Adam Roach Date: Tue, 26 Jan 2010 11:33:47 -0500 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqeoWBhwNSKhv+rRaqy/FdXIeowiwAAuzJw Message-ID: References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> <4B5F12B3.5020701@nostrum.com> In-Reply-To: <4B5F12B3.5020701@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1C6Email_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:33:48 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1C6Email_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not proposing a solution that ignores DNS wholesale. I'm proposing a m= echanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.= g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from= domain-A. How a request gets to domain-A is not a problem for Martini. I= f someone chooses to provision DNS such that domain-B has an entry which po= ints to domain-A, that's their issue and I'm neither condoning it nor menti= oning it. I can't stop people from having host files or local policy overr= ides either. -hadriel ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, January 26, 2010 11:05 AM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: Not at all - I have no idea what Braniff would want to do (probably use ada= m@verizon.com, since Verizon now owns Braniff's fo= rmer headquarters building :)). But seriously, how a request to adam@braniff.com h= appened to get to centricvoice's proxies does not matter... It kind of does. If you're proposing a solution that is predicated on ignor= ing DNS wholesale, then you've just amplified the alt-root problem by sever= al orders of magnitude. The answer to that question must be "it works AT LEAST for the cases in whi= ch RFC 3263 routing procedures took it to the SSP". If you want to make it = work for other scenarios, that's fine. But if you're designing a solution t= hat cannot work on the Internet at large, then it really won't fly. /a --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1C6Email_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not proposing a solution tha= t ignores DNS wholesale.  I’m proposing a mechanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from domain-A.  How a request gets to domain-A is not a problem for Martini.  If someone cho= oses to provision DNS such that domain-B has an entry which points to domain-A, = that’s their issue and I’m neither condoning it nor mentioning it.  I c= an’t stop people from having host files or local policy overrides either. <= /o:p>

 

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2= 010 11:05 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:

Not at all – I have no idea what Braniff would want= to do (probably use adam@verizon.com, since Verizon now owns Braniff’s former headquarters building = J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter...

=
It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-ro= ot problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases i= n which RFC 3263 routing procedures took it to the SSP". If you want to = make it work for other scenarios, that's fine. But if you're designing a solutio= n that cannot work on the Internet at large, then it really won't fly.

/a

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1C6Email_-- From bruno.chatras@orange-ftgroup.com Tue Jan 26 08:34:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D326A3A68A9 for ; Tue, 26 Jan 2010 08:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 vniGbvQVKSwS for ; Tue, 26 Jan 2010 08:34:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id C1DCB3A67B6 for ; Tue, 26 Jan 2010 08:34:20 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3598F3745DF; Tue, 26 Jan 2010 17:34:31 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1E76B18004D; Tue, 26 Jan 2010 17:34:31 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 17:34:30 +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, 26 Jan 2010 17:34:29 +0100 Message-ID: <13208_1264523671_4B5F1997_13208_14014_1_9ECCF01B52E7AB408A7EB85352642141010536C7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B5F18C2.1050305@shockey.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev2 Thread-Index: AcqepPU+Ap01mwVjSZqVJ8GC6HOL6wAACdkw References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com><778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> <4B5F18C2.1050305@shockey.us> From: To: , X-OriginalArrivalTime: 26 Jan 2010 16:34:30.0725 (UTC) FILETIME=[6F47CF50:01CA9EA5] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.142419 Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:34:22 -0000 On the other hand it would be a bit odd to define a solution that works exc= lusively for E.164 numbers and have to use a different solution for email-s= tyle URI and private numbers.=20 > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Richard Shockey > Envoy=E9 : mardi 26 janvier 2010 17:31 > =C0 : martini@ietf.org > Objet : Re: [martini] Requirements - rev2 >=20 >=20 > Dean ...typically the business context for MARTINI is almost=20 > exclusively E.164 naming where the SSP is in direct=20 > ownership/control of the Layer 1 connection. >=20 > And yes .. I need to respond to Paul on the issues with=20 > assuming block number routing. This will become increasingly=20 > relevant as LNP rolls out in the EC. >=20 > On 1/26/2010 10:44 AM, Dean Willis wrote: > > > > On Jan 25, 2010, at 5:40 PM, Paul Kyzivat wrote: > > > >> Spencer, > >> > >> I guess this needs to be segmented into separate issues, which you=20 > >> have already more or less done: ... > > > > > > Excellent summary. One additional issue: > > > > Are the user-part identifiers restricted to being only=20 > encoded E.164=20 > > numbers? Or is a more general user-part syntax allowed? > > > > If we restrict ourselves to E.164 user-parts, then a lot of the=20 > > complexity evaporates. > > > > > > This brings a related issue: Are we talking about sip:=20 > request URIs or > > tel: request URIs? > > > > -- > > Dean > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > >=20 > -- > Richard Shockey > Shockey Consulting > Chairman of Board SIP Forum > Voice +1 703 593 2683 > Skype etc : rshockey101 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Tue Jan 26 08:36:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063223A681B for ; Tue, 26 Jan 2010 08:36:22 -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, 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 X3Z39JECW+By for ; Tue, 26 Jan 2010 08:36:17 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9FE983A67B6 for ; Tue, 26 Jan 2010 08:36:16 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QGaNY6026723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 10:36:24 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F1A07.4010109@nostrum.com> Date: Tue, 26 Jan 2010 10:36:23 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> <4B5F12B3.5020701@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090809060706060209000204" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:36:22 -0000 This is a multi-part message in MIME format. --------------090809060706060209000204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Okay, so we're in agreement that it must work at least for the cases in which RFC 3263 resolution procedures on the PBX's domain resolve to an IP address belonging to one of the SSP's servers. Right? /a On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote: > > I'm not proposing a solution that ignores DNS wholesale. I'm > proposing a mechanism for routing a request from domain-A (e.g., an > SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used > for reaching domain-B from domain-A. How a request gets to domain-A > is not a problem for Martini. If someone chooses to provision DNS > such that domain-B has an entry which points to domain-A, that's their > issue and I'm neither condoning it nor mentioning it. I can't stop > people from having host files or local policy overrides either. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* Tuesday, January 26, 2010 11:05 AM > *To:* Hadriel Kaplan > *Cc:* martini@ietf.org > *Subject:* Re: [martini] The much maligned Request-URI > > On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: > > Not at all -- I have no idea what Braniff would want to do (probably > use adam@verizon.com , since Verizon now owns > Braniff's former headquarters building J). > > But seriously, how a request to adam@braniff.com > happened to get to centricvoice's proxies > does not matter... > > > It kind of does. If you're proposing a solution that is predicated on > ignoring DNS wholesale, then you've just amplified the alt-root > problem by several orders of magnitude. > > The answer to that question must be "it works AT LEAST for the cases > in which RFC 3263 routing procedures took it to the SSP". If you want > to make it work for other scenarios, that's fine. But if you're > designing a solution that cannot work on the Internet at large, then > it really won't fly. > > /a > --------------090809060706060209000204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Okay, so we're in agreement that it must work at least for the cases in which RFC 3263 resolution procedures on the PBX's domain resolve to an IP address belonging to one of the SSP's servers. Right?

/a

On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote:

I’m not proposing a solution that ignores DNS wholesale.  I’m proposing a mechanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from domain-A.  How a request gets to domain-A is not a problem for Martini.  If someone chooses to provision DNS such that domain-B has an entry which points to domain-A, that’s their issue and I’m neither condoning it nor mentioning it.  I can’t stop people from having host files or local policy overrides either.

 

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2010 11:05 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The much maligned Request-URI

 

On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:

Not at all – I have no idea what Braniff would want to do (probably use adam@verizon.com, since Verizon now owns Braniff’s former headquarters building J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter...


It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases in which RFC 3263 routing procedures took it to the SSP". If you want to make it work for other scenarios, that's fine. But if you're designing a solution that cannot work on the Internet at large, then it really won't fly.

/a


--------------090809060706060209000204-- From dean.willis@softarmor.com Tue Jan 26 08:40:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980B83A67B6 for ; Tue, 26 Jan 2010 08:40:08 -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 LLiN3AiI7bYT for ; Tue, 26 Jan 2010 08:40:07 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0E49B3A681B for ; Tue, 26 Jan 2010 08:40:07 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGeCZY017648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 10:40:14 -0600 Message-Id: <42640910-830D-4A72-90B1-0F8749A26F35@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 10:40:07 -0600 References: X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:40:08 -0000 On Jan 26, 2010, at 9:32 AM, Hadriel Kaplan wrote: > > I don't think Option-1 is a real option. As far as I know, in > virtually all cases of IP-PBX trunking I've been involved with, by > the time the request gets to the IP-PBX, the req-uri's domain/host > portion identifies the IP-PBX's domain or host/IP. It may not be > the routing proxy-registrar which does it, but a middlebox > instead... but it will get changed if it wasn't already right. But if the request had originally encoded "a domain belonging to the PBX", why does it get changed? You're starting with the assumption that the request originally targeted some other domain. > > That's consistent with what *should* happen, because if the request > was sip:foobar@ssp.com and was routed to pbx.com, then it got > *retargeted*. Luckily (or not) retargeting rules are basically > completely open in 3261. We can do whatever magic we want to. Hold on a sec. The idea behind MARTINI is that the request was NOT routed to the service provider, but was route to a domain "owned" by the customer (OBX), and for which the SSP is providing a relay service. So what's our problem space again? -- Dean From adam@nostrum.com Tue Jan 26 08:41:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F372E3A681B for ; Tue, 26 Jan 2010 08:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IupXSeV65qdY for ; Tue, 26 Jan 2010 08:41:42 -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 BCD6A3A67B6 for ; Tue, 26 Jan 2010 08:41:41 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QGfodv027123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 10:41:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F1B4E.1090208@nostrum.com> Date: Tue, 26 Jan 2010 10:41:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:41:43 -0000 On 1/26/10 09:52, Jan 26, Dean Willis wrote: > > On Jan 26, 2010, at 2:16 AM, Elwell, John wrote: > >> Changing the thread name to focus on another issue. >> >> We seem to have converged on what Adam calls contact routing, which >> basically says that the domain part of the Request-URI in an inbound >> request should contain the domain part of the registered contact URI, >> leaving the user part to identify the particular AOR. I think this >> does indeed correspond to one of the practices seen in the wild at >> present. >> > > That's not contact-routing, and I don't THINK it's what Adam means. I > think Adam means that there MUST be a unique contact URI for each AOR. Right. /a From dean.willis@softarmor.com Tue Jan 26 08:43:22 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C354E3A681B for ; Tue, 26 Jan 2010 08:43:22 -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 ksJxGYe00pFt for ; Tue, 26 Jan 2010 08:43:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A7F0F3A67B6 for ; Tue, 26 Jan 2010 08:43:20 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGhSAL017692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 10:43:29 -0600 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 10:43:23 -0600 References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:43:22 -0000 On Jan 26, 2010, at 9:42 AM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf >> Of Spencer Dawkins >> Sent: Tuesday, January 26, 2010 8:47 AM >> >> The problem with user@enterprise.com is that requests from outside >> the >> service provider to this AOR would go straight to the SIP-PBX without >> traversing any service provider proxy - unless we dork with two- >> faced DNS, >> etc. > > *We* (martini) won't be dorking with anything. How a request got to > the SSP is effectively out of scope for this WG, right? For all I > know, the request originated in the SSP. The question isn't how it > got to the SSP - the question is what the SSP should do about it > once it gets it. :) One possible assumption is that the request got to the SSP because RFC 3263 procedures POINTED the request to the SSP. This means we can't use RFC 3263 procedures to get the request from the SSP to the PBX, unless the SP retargets the request somehow. So yeah, it DOES put constraints on the solution space. -- Dean From HKaplan@acmepacket.com Tue Jan 26 08:43:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DEA3A67B6 for ; Tue, 26 Jan 2010 08:43: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 odqVY97LldQ7 for ; Tue, 26 Jan 2010 08:43:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 819BD3A681B for ; Tue, 26 Jan 2010 08:43:27 -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; Tue, 26 Jan 2010 11:43:37 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 11:43:37 -0500 From: Hadriel Kaplan To: Spencer Dawkins , "bruno.chatras@orange-ftgroup.com" , "john.elwell@siemens-enterprise.com" , "adam@nostrum.com" Date: Tue, 26 Jan 2010 11:43:36 -0500 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: AcqeonQ8ma6q1iDrT7SKw53D4lQbmgAAuepg Message-ID: References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:43:29 -0000 Well of course they can - and they can do it right now too. So what? As l= ong as we don't advocate it or rely on it. And we *don't* rely on it. Who= 's to say the request can't go direct to the Enterprise? It's a local poli= cy decision if the Enterprise wants to accept it, of course, but as far as = Martini is concerned it can. The question is if a UA in SSP's domain sends a request to sip:foobar@PBX.c= om through its SSP proxy-registrar, what should the SSP proxy-registrar do = with the req-uri? Option-1: leave it alone but insert the registered path/contact info as Rou= te-header URIs Option-2: replace it with some form of the registered contact-URI I vote option-1. The second problem is what if the SSP gets sip:foobar@SSP.com, and I propos= e that it retarget it, and also insert the Route list of the path/contact (= because after retargeting it would then follow Option-1 above again). The question is if the retargeting function details should be prescribed by= a SIP-Forum document, or by an IETF document, or prescribed by the IP-PBX = in its registration through some body list/regex-formula, or left to random= implementations. -hadriel > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > Sent: Tuesday, January 26, 2010 11:13 AM > To: Hadriel Kaplan; bruno.chatras@orange-ftgroup.com; john.elwell@siemens= - > enterprise.com; adam@nostrum.com > Cc: martini@ietf.org > Subject: Re: [martini] Enumerating AORs/contacts >=20 > Hi, Hadriel, >=20 > Sorry for being imprecise. "unless the service provider dorks with two- > faced > DNS" - that's the "we" I meant. >=20 > And I'm not suggesting that service providers dork with two-faced DNS - > just > that it's one of the alternatives I can imagine someone implementing > quickly > as a shortcut. >=20 > Thanks, >=20 > Spencer >=20 > ------------------------ >=20 > > The problem with user@enterprise.com is that requests from outside the > > service provider to this AOR would go straight to the SIP-PBX without > > traversing any service provider proxy - unless we dork with two-faced > DNS, > > etc. >=20 > *We* (martini) won't be dorking with anything. How a request got to the > SSP > is effectively out of scope for this WG, right? For all I know, the > request > originated in the SSP. The question isn't how it got to the SSP - the > question is what the SSP should do about it once it gets it. :) >=20 > -hadriel From dean.willis@softarmor.com Tue Jan 26 08:47:19 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AE13A67C1 for ; Tue, 26 Jan 2010 08:47:19 -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 D9qJPV0CbSkq for ; Tue, 26 Jan 2010 08:47:18 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8C8BE3A63EC for ; Tue, 26 Jan 2010 08:47:18 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGl3jh017719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 10:47:04 -0600 Message-Id: <45445FBD-374F-49D5-9746-9B881070CFCE@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 10:46:57 -0600 References: X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:47:19 -0000 On Jan 26, 2010, at 10:03 AM, Cullen Jennings wrote: > > On Jan 8, 2010, at 10:46 AM, Elwell, John wrote: > >> - The mechanism MUST allow the PBX to be responsible for its AORs >> and to handle requests to those AORs according to its rules. > > Is it OK for the SSP to send the call to voicemail? I'm not arguing > one way or the other here, I'm just trying to figure out if the SSP > or PBX is responsible for the AOR? and in particular: Does the SSP use Service-Route to dispatch the call to application servers in order to "service" the call? -- Dean From drage@alcatel-lucent.com Tue Jan 26 08:48:34 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70603A686C for ; Tue, 26 Jan 2010 08:48:34 -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_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 hvwzebTwPiID for ; Tue, 26 Jan 2010 08:48:33 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 8944F3A67CC for ; Tue, 26 Jan 2010 08:48:33 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o0QGmCCV021932 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Jan 2010 17:48:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Jan 2010 17:47:54 +0100 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , "Elwell, John" Date: Tue, 26 Jan 2010 17:47:52 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqeoUFucZ9vwHt+S2242Lx0fcoLeAABCLjQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:48:35 -0000 I've just read my way through this entire thread again. So going back to the start, what IMS does is mechanism 1), not 3). If does this on the basis that we are trying to simulate as much as possibl= e what a proxy doing an ordinary DNS look up would do. However it includes = the extra Route header value because it needs to get through the rest of th= e IMS proxies to the gateway PBX. As such any issues probably exist in the straight network peering solution = as well. I would make the following points: 1) Dean quite rightly stated that the enterprise operator is devolving some= responsibility to the SSP. In TISPAN/3GPP, the view is essentially that th= e SSP is providing some form of virtual transit PBX, which the SSP rents to= the enterprise provider.So the devolving of DNS responsibility is on the b= asis of that. 2) The number routing problem is no different to that that exists between t= wo SSPs. If you are a user with 123 @ ssp_example1 and I make a call to 123= @ ssp_example2, what does ssp_example2 do with this call. Either it ignore= s the domain name and processes it anyway - something that is not allowed b= y IETF but many operators do anyway, or it rejects the call. I don't expect= anything different to happen in the business trunking. Thus the correct ad= dress for users on the PBX is number@pbx.com, not number@ssp.com. How the S= SP handles number@ssp.com is not going to alter based on an IETF edict, but= it will be the SSP breaking the rules. regards Keith > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Tuesday, January 26, 2010 4:04 PM > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 >=20 > On Jan 8, 2010, at 10:46 AM, Elwell, John wrote: >=20 > > - The mechanism MUST allow the PBX to be responsible for=20 > its AORs and to handle requests to those AORs according to its rules. >=20 > Is it OK for the SSP to send the call to voicemail? I'm not=20 > arguing one way or the other here, I'm just trying to figure=20 > out if the SSP or PBX is responsible for the AOR? >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From dean.willis@softarmor.com Tue Jan 26 08:49:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D14B3A67F4 for ; Tue, 26 Jan 2010 08:49:58 -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 NifsHhpWTWJL for ; Tue, 26 Jan 2010 08:49:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3805D3A63EC for ; Tue, 26 Jan 2010 08:49:57 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGo42x017755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 10:50:06 -0600 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <4B5F18C2.1050305@shockey.us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jan 2010 10:49:59 -0600 References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com> <778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> <4B5F18C2.1050305@shockey.us> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:49:58 -0000 On Jan 26, 2010, at 10:30 AM, Richard Shockey wrote: > > Dean ...typically the business context for MARTINI is almost > exclusively E.164 naming where the SSP is in direct ownership/ > control of the Layer 1 connection. > > And yes .. I need to respond to Paul on the issues with assuming > block number routing. This will become increasingly relevant as LNP > rolls out in the EC. Well, if we're willing to constrain our solution to E.164, then it can be a whole heck of a lot simpler. Or we could do a solution NOW that works for the E.164 restriction, and put off solving the general domain routing problem for phase 2. I'd be willing to entertain a solution that is only applicable to E. 164. Do we want to do it this way? -- Dean From adam@nostrum.com Tue Jan 26 08:50:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549423A67F4 for ; Tue, 26 Jan 2010 08:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oW0n80dvVI-A for ; Tue, 26 Jan 2010 08:50:13 -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 152283A67CC for ; Tue, 26 Jan 2010 08:50:12 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QGoKhH027823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 10:50:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F1D4C.6080301@nostrum.com> Date: Tue, 26 Jan 2010 10:50:20 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:50:14 -0000 On 1/26/10 10:43, Jan 26, Hadriel Kaplan wrote: > Well of course they can - and they can do it right now too. So what? As long as we don't advocate it or rely on it. And we *don't* rely on it. Who's to say the request can't go direct to the Enterprise? It's a local policy decision if the Enterprise wants to accept it, of course, but as far as Martini is concerned it can. > > The question is if a UA in SSP's domain sends a request to sip:foobar@PBX.com through its SSP proxy-registrar, what should the SSP proxy-registrar do with the req-uri? > Option-1: leave it alone but insert the registered path/contact info as Route-header URIs > Option-2: replace it with some form of the registered contact-URI > > I vote option-1. > And I could kind of see where this was coming from, if we were using something other than REGISTER to define this routing information. But the type of operation you describe in option-1 has never been associated with REGISTER. The thing you're describing in option-1 is effectively a site-local DNS override, not an AOR => Contact binding. /a From HKaplan@acmepacket.com Tue Jan 26 08:51:54 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD433A67CC for ; Tue, 26 Jan 2010 08:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YMaDhGTemGVR for ; Tue, 26 Jan 2010 08:51:45 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1F46B3A67F4 for ; Tue, 26 Jan 2010 08:51:45 -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; Tue, 26 Jan 2010 11:51:54 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 11:51:54 -0500 From: Hadriel Kaplan To: Adam Roach Date: Tue, 26 Jan 2010 11:51:54 -0500 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqepbQRpzHI76P6QHGaRUjLW5ESSQAAXMdw Message-ID: References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> <4B5F12B3.5020701@nostrum.com> <4B5F1A07.4010109@nostrum.com> In-Reply-To: <4B5F1A07.4010109@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1CD8mail_" MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:51:54 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1CD8mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure I guess, but why is that a requirement for Martini? I'm not trying to= be belligerent, but I just don't see why those details matter for the prob= lem at hand. For all I care, the DNS can point to the PBX, which can send = a 302 redirect to all requests not from its SSP, redirecting to its SSP. -hadriel ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, January 26, 2010 11:36 AM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI Okay, so we're in agreement that it must work at least for the cases in whi= ch RFC 3263 resolution procedures on the PBX's domain resolve to an IP addr= ess belonging to one of the SSP's servers. Right? /a On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote: I'm not proposing a solution that ignores DNS wholesale. I'm proposing a m= echanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.= g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from= domain-A. How a request gets to domain-A is not a problem for Martini. I= f someone chooses to provision DNS such that domain-B has an entry which po= ints to domain-A, that's their issue and I'm neither condoning it nor menti= oning it. I can't stop people from having host files or local policy overr= ides either. -hadriel ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, January 26, 2010 11:05 AM To: Hadriel Kaplan Cc: martini@ietf.org Subject: Re: [martini] The much maligned Request-URI On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: Not at all - I have no idea what Braniff would want to do (probably use ada= m@verizon.com, since Verizon now owns Braniff's fo= rmer headquarters building :)). But seriously, how a request to adam@braniff.com h= appened to get to centricvoice's proxies does not matter... It kind of does. If you're proposing a solution that is predicated on ignor= ing DNS wholesale, then you've just amplified the alt-root problem by sever= al orders of magnitude. The answer to that question must be "it works AT LEAST for the cases in whi= ch RFC 3263 routing procedures took it to the SSP". If you want to make it = work for other scenarios, that's fine. But if you're designing a solution t= hat cannot work on the Internet at large, then it really won't fly. /a --_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1CD8mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Sure I guess, but why is that a requirement for Martini?  I’m not trying to be belligerent, but = I just don’t see why those details matter for the problem at hand.  For all I care,= the DNS can point to the PBX, which can send a 302 redirect to all requests not fro= m its SSP, redirecting to its SSP.

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2= 010 11:36 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= Okay, so we're in agreement that it must work at= least for the cases in which RFC 3263 resolution procedures on the PBX's domain resolve to an IP address belonging to one of the SSP's servers. Right?

/a

On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote:

I’m not proposing a solution that ignores DNS whole= sale.  I’m proposing a mechanism for routing a request from domain-A (= e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from domain-A.  How a request gets to domain-A is no= t a problem for Martini.  If someone chooses to provision DNS such that domain-B has an entry which points to domain-A, that’s their issue an= d I’m neither condoning it nor mentioning it.  I can’t stop people fro= m having host files or local policy overrides either.

 =

-hadriel

 =

From: Adam Roach [mailto:a= dam@nostrum.com]
Sent: Tuesday, January 26, 2= 010 11:05 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The m= uch maligned Request-URI

=  

= On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: <= /u1:p>

Not at all – I have no idea what Braniff would want= to do (probably use ad= am@verizon.com, since Verizon now owns Braniff’s former headquarters building J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter...

=
It kind of does. If you're proposing a solution that is predicated on ignor= ing DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases i= n which RFC 3263 routing procedures took it to the SSP". If you want to = make it work for other scenarios, that's fine. But if you're designing a solutio= n that cannot work on the Internet at large, then it really won't fly.

/a

=  

--_000_E6C2E8958BA59A4FB960963D475F7AC31A5A1D1CD8mail_-- From dean.willis@softarmor.com Tue Jan 26 08:53:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5DDF3A67C0 for ; Tue, 26 Jan 2010 08:53: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=[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 0r+unBH1UJ6G for ; Tue, 26 Jan 2010 08:53:18 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D995F3A63EC for ; Tue, 26 Jan 2010 08:53:17 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGrQPl017823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Jan 2010 10:53:28 -0600 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <4B5F1B4E.1090208@nostrum.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: Tue, 26 Jan 2010 10:53:21 -0600 References: <4B4F520C.9000208@nostrum.com><4B5283C4.9080700@nostrum.com> <51AABAC7-B5A7-4ED5-B07B-13C0CFDB4C87@softarmor.com> <4B5DE61F.70302@nostrum.com> <4B5F1B4E.1090208@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:53:18 -0000 On Jan 26, 2010, at 10:41 AM, Adam Roach wrote: > On 1/26/10 09:52, Jan 26, Dean Willis wrote: >> >> On Jan 26, 2010, at 2:16 AM, Elwell, John wrote: >>> >>> We seem to have converged on what Adam calls contact routing, >>> which basically says that the domain part of the Request-URI in an >>> inbound request should contain the domain part of the registered >>> contact URI, leaving the user part to identify the particular AOR. >>> I think this does indeed correspond to one of the practices seen >>> in the wild at present. >>> >> >> That's not contact-routing, and I don't THINK it's what Adam means. >> I think Adam means that there MUST be a unique contact URI for each >> AOR. > > Right. > And, as you have pointed out, such uniqueness could be produced using several techniques, including 1) varying the domain-part or 2) varying the user-part or 3) varying both. But SOMETHING has to be different so that the requests can be differentiated at the PBX! -- Dean From adam@nostrum.com Tue Jan 26 08:55:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899AB3A67C0 for ; Tue, 26 Jan 2010 08:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 J6iCjmpWOA-A for ; Tue, 26 Jan 2010 08:55:07 -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 7B4043A63EC for ; Tue, 26 Jan 2010 08:55:07 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QGtGpP028204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 10:55:16 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F1E74.2050305@nostrum.com> Date: Tue, 26 Jan 2010 10:55:16 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com> <778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com> <4B5F18C2.1050305@shockey.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:55:08 -0000 On 1/26/10 10:49, Jan 26, Dean Willis wrote: > I'd be willing to entertain a solution that is only applicable to > E.164. Do we want to do it this way? The problem here, as has been raised before, is: how can you tell if the user portion is an E.164 number? The obvious answers are that it must not apply unless the R-URI is a tel: URL or contains a "user=phone" parameter. At that point, the issue of "proper" domain handling becomes much less important. /a From dean.willis@softarmor.com Tue Jan 26 08:56:14 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BF73A67CC for ; Tue, 26 Jan 2010 08:56: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=[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 cMowq9EjQsfo for ; Tue, 26 Jan 2010 08:56:14 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3A2E63A67C0 for ; Tue, 26 Jan 2010 08:56:14 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0QGuN66017894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jan 2010 10:56:24 -0600 Message-Id: From: Dean Willis To: martini@ietf.org In-Reply-To: <42640910-830D-4A72-90B1-0F8749A26F35@softarmor.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: Tue, 26 Jan 2010 10:56:17 -0600 References: <42640910-830D-4A72-90B1-0F8749A26F35@softarmor.com> X-Mailer: Apple Mail (2.936) Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:56:15 -0000 On Jan 26, 2010, at 10:40 AM, Dean Willis wrote: > > Hold on a sec. The idea behind MARTINI is that the request was NOT > routed to the service provider, but was route to a domain "owned" by > the customer (OBX), and for which the SSP is providing a relay > service. I mean "but was routed to a domain "owned" by the customer (PBX)". Keys are too close together on this keyboard! But apparently you folks knew what I meant anyhow. -- Dean From HKaplan@acmepacket.com Tue Jan 26 08:58:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F98D3A67C0 for ; Tue, 26 Jan 2010 08:58:51 -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 Mmg3MWql4507 for ; Tue, 26 Jan 2010 08:58:50 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5CB893A67B6 for ; Tue, 26 Jan 2010 08:58:50 -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; Tue, 26 Jan 2010 11:59:00 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jan 2010 11:59:00 -0500 From: Hadriel Kaplan To: Adam Roach Date: Tue, 26 Jan 2010 11:58:59 -0500 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqep6aOmmDRJojgQ1asqMB/bgbKXQAAGa0g Message-ID: References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> <4B5F1D4C.6080301@nostrum.com> In-Reply-To: <4B5F1D4C.6080301@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 16:58:51 -0000 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, January 26, 2010 11:50 AM > To: Hadriel Kaplan > Cc: Spencer Dawkins; bruno.chatras@orange-ftgroup.com; > john.elwell@siemens-enterprise.com; martini@ietf.org > Subject: Re: [martini] Enumerating AORs/contacts >=20 > On 1/26/10 10:43, Jan 26, Hadriel Kaplan wrote: > > The question is if a UA in SSP's domain sends a request to > sip:foobar@PBX.com through its SSP proxy-registrar, what should the SSP > proxy-registrar do with the req-uri? > > Option-1: leave it alone but insert the registered path/contact info as > Route-header URIs > > Option-2: replace it with some form of the registered contact-URI > > > > I vote option-1. > > >=20 > And I could kind of see where this was coming from, if we were using > something other than REGISTER to define this routing information. But > the type of operation you describe in option-1 has never been associated > with REGISTER. The thing you're describing in option-1 is effectively a > site-local DNS override, not an AOR =3D> Contact binding. That's why we're talking about a standards-track document and an options-ta= g rather than a BCP. :) You make it sound like the "REGISTER" method is immutable as to the logic w= hich a registrar-proxy performs and derives routing information from its en= tries. What is so sacrosanct about a REGISTER that all derivative informat= ion cannot be used for new procedures? Is it covered by GPL 3.0? -hadriel From adam@nostrum.com Tue Jan 26 08:59:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7233A63EC for ; Tue, 26 Jan 2010 08:59:59 -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, 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 KMH6EvLFgO2F for ; Tue, 26 Jan 2010 08:59:55 -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 54DC63A67C0 for ; Tue, 26 Jan 2010 08:59:54 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0QH01k3028515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 11:00:01 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B5F1F90.10909@nostrum.com> Date: Tue, 26 Jan 2010 11:00:00 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> <4B5F12B3.5020701@nostrum.com> <4B5F1A07.4010109@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050505070104080108010407" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:00:00 -0000 This is a multi-part message in MIME format. --------------050505070104080108010407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It matters because it helps nail down the use cases we're talking about. We need to come to some consensus about who is "responsible" -- in the RFC 3261 sense of that word (that is, as RFC 3261 uses it in normative statements) -- for the domain in the request URI. /a On 1/26/10 10:51, Jan 26, Hadriel Kaplan wrote: > > Sure I guess, but why is that a requirement for Martini? I'm not > trying to be belligerent, but I just don't see why those details > matter for the problem at hand. For all I care, the DNS can point to > the PBX, which can send a 302 redirect to all requests not from its > SSP, redirecting to its SSP. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* Tuesday, January 26, 2010 11:36 AM > *To:* Hadriel Kaplan > *Cc:* martini@ietf.org > *Subject:* Re: [martini] The much maligned Request-URI > > Okay, so we're in agreement that it must work at least for the cases > in which RFC 3263 resolution procedures on the PBX's domain resolve to > an IP address belonging to one of the SSP's servers. Right? > > /a > > On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote: > > I'm not proposing a solution that ignores DNS wholesale. I'm > proposing a mechanism for routing a request from domain-A (e.g., an > SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used > for reaching domain-B from domain-A. How a request gets to domain-A > is not a problem for Martini. If someone chooses to provision DNS > such that domain-B has an entry which points to domain-A, that's their > issue and I'm neither condoning it nor mentioning it. I can't stop > people from having host files or local policy overrides either. > > -hadriel > > ------------------------------------------------------------------------ > > *From:* Adam Roach [mailto:adam@nostrum.com] > *Sent:* Tuesday, January 26, 2010 11:05 AM > *To:* Hadriel Kaplan > *Cc:* martini@ietf.org > *Subject:* Re: [martini] The much maligned Request-URI > > On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote: > > Not at all -- I have no idea what Braniff would want to do (probably > use adam@verizon.com , since Verizon now owns > Braniff's former headquarters building J). > > But seriously, how a request to adam@braniff.com > happened to get to centricvoice's proxies > does not matter... > > > It kind of does. If you're proposing a solution that is predicated on > ignoring DNS wholesale, then you've just amplified the alt-root > problem by several orders of magnitude. > > The answer to that question must be "it works AT LEAST for the cases > in which RFC 3263 routing procedures took it to the SSP". If you want > to make it work for other scenarios, that's fine. But if you're > designing a solution that cannot work on the Internet at large, then > it really won't fly. > > /a > --------------050505070104080108010407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It matters because it helps nail down the use cases we're talking about. We need to come to some consensus about who is "responsible" -- in the RFC 3261 sense of that word (that is, as RFC 3261 uses it in normative statements) -- for the domain in the request URI.

/a


On 1/26/10 10:51, Jan 26, Hadriel Kaplan wrote:

 

Sure I guess, but why is that a requirement for Martini?  I’m not trying to be belligerent, but I just don’t see why those details matter for the problem at hand.  For all I care, the DNS can point to the PBX, which can send a 302 redirect to all requests not from its SSP, redirecting to its SSP.

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2010 11:36 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The much maligned Request-URI

 

Okay, so we're in agreement that it must work at least for the cases in which RFC 3263 resolution procedures on the PBX's domain resolve to an IP address belonging to one of the SSP's servers. Right?

/a

On 1/26/10 10:33, Jan 26, Hadriel Kaplan wrote:

I’m not proposing a solution that ignores DNS wholesale.  I’m proposing a mechanism for routing a request from domain-A (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where DNS cannot be used for reaching domain-B from domain-A.  How a request gets to domain-A is not a problem for Martini.  If someone chooses to provision DNS such that domain-B has an entry which points to domain-A, that’s their issue and I’m neither condoning it nor mentioning it.  I can’t stop people from having host files or local policy overrides either.

 

-hadriel

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Tuesday, January 26, 2010 11:05 AM
To: Hadriel Kaplan
Cc: martini@ietf.org
Subject: Re: [martini] The much maligned Request-URI

 

On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:

Not at all – I have no idea what Braniff would want to do (probably use adam@verizon.com, since Verizon now owns Braniff’s former headquarters building J).

But seriously, how a request to adam@braniff.com happened to get to centricvoice’s proxies does not matter...


It kind of does. If you're proposing a solution that is predicated on ignoring DNS wholesale, then you've just amplified the alt-root problem by several orders of magnitude.

The answer to that question must be "it works AT LEAST for the cases in which RFC 3263 routing procedures took it to the SSP". If you want to make it work for other scenarios, that's fine. But if you're designing a solution that cannot work on the Internet at large, then it really won't fly.

/a

 


--------------050505070104080108010407-- From pkyzivat@cisco.com Tue Jan 26 09:10:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500873A681B for ; Tue, 26 Jan 2010 09:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSAvCicnd46L for ; Tue, 26 Jan 2010 09:10:36 -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 7A6113A63EC for ; Tue, 26 Jan 2010 09:10:36 -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: ApoEAGqxXkurRN+K/2dsb2JhbADDa5ckhDkE X-IronPort-AV: E=Sophos;i="4.49,347,1262563200"; d="scan'208";a="79221605" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Jan 2010 17:10:47 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0QHAlPM024924; Tue, 26 Jan 2010 17:10:47 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 11:10:47 -0600 Received: from [10.86.240.105] ([10.86.240.105]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 11:10:46 -0600 Message-ID: <4B5F2223.1020407@cisco.com> Date: Tue, 26 Jan 2010 12:10:59 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C40F1FF@zcarhxm1.corp.nortel.com> <12909_1264521206_4B5F0FF6_12909_64141_1_9ECCF01B52E7AB408A7EB85352642141010535FE@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <12909_1264521206_4B5F0FF6_12909_64141_1_9ECCF01B52E7AB408A7EB85352642141010535FE@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jan 2010 17:10:47.0060 (UTC) FILETIME=[807A2D40:01CA9EAA] Cc: martini@ietf.org, HKaplan@acmepacket.com Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:10:40 -0000 bruno.chatras@orange-ftgroup.com wrote: > Then we could ask whether there are other SIP-based architectures that would require the list of implictly registered identities to be conveyed from the registrar to the edge proxy. If the answer if no and the use of P-Associated-URI is not deprecated in IMS-based networks, I'm not sure it's worth extending the reg-event event package. Why would the reg event package need to be extended? Paul >> -----Message d'origine----- >> De : Brian Lindsay [mailto:blindsay@nortel.com] >> Envoyé : mardi 26 janvier 2010 16:48 >> À : CHATRAS Bruno RD-CORE-ISS; HKaplan@acmepacket.com; >> martini@ietf.org >> Objet : RE: [martini] Listing the implicitly registered AoR's >> >> Hi, >> >> I think that's fine. We just don't need to bring the >> requirement into the Martini draft. Such systems may have >> incremental requirements above/beyond Martini. >> >> -----Original Message----- >> From: bruno.chatras@orange-ftgroup.com >> [mailto:bruno.chatras@orange-ftgroup.com] >> Sent: Tuesday, January 26, 2010 10:45 AM >> To: HKaplan@acmepacket.com; Lindsay, Brian (CAR:AR00); >> martini@ietf.org >> Subject: RE: [martini] Listing the implicitly registered AoR's >> >> I assume that IMS-based networks would continue to use >> P-Associated-URI in their "closed" environnements rather than >> use an extended reg-event package. I'v not seen any proposal >> to deprecate RFC3455 anyway... >> >>> -----Message d'origine----- >>> De : martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] De la part de Hadriel >> Kaplan Envoyé >>> : mardi 26 janvier 2010 16:34 À : Brian Lindsay; martini@ietf.org >>> Objet : Re: [martini] Listing the implicitly registered AoR's >>> >>> >>> Hi Brian, >>> I _think_ that's consistent with using reg-event, because >> we wouldn't >>> document a requirement to use reg-event, just note that it could be >>> used for that purpose (if even that). >>> >>> -hadriel >>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On >>>> Behalf Of Brian Lindsay >>>> Sent: Tuesday, January 26, 2010 10:15 AM >>>> To: Hadriel Kaplan; martini@ietf.org >>>> Subject: Re: [martini] Listing the implicitly registered AoR's >>>> >>>> Hi Hadriel, >>>> >>>> I don't think this needs to be spelled out in the draft. >>> There may >>>> be specific solutions/architectures like IMS that would use >>> this, and >>>> that's OK, but I don't believe this is central to the >>>> mechanism/interface in the draft. >>>> >>>> Thanks >>>> Brian >>>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On >>>> Behalf Of Hadriel Kaplan >>>> Sent: Tuesday, January 26, 2010 10:02 AM >>>> To: martini@ietf.org >>>> Subject: [martini] Listing the implicitly registered AoR's >>>> >>>> On the topic of listing implicitly registered AoR's (what >> has been >>>> done so far in P-Associated-URI), the emails on this seem >>> to focus on >>>> either requiring it, or not at all. But there was a third option >>>> proposed by someone on the last virtual meeting call: use >>> reg-event for that. >>>> In other words, don't put them in a PAU/whatever of the >> REGISTER (or >>>> PUBLISH) request or response. Instead, use the subscription for >>>> reg-event to list them. In the P-CSCF/edge-proxy case, the >>> edge-proxy >>>> itself can subscribe to that package after the IP-PBX has >>> registered >>>> itself. >>>> >>>> That seemed like a good compromise to me. (I preferred >> having it in >>>> the REGISTER response, but we can't have everything :) >>>> >>>> -hadriel >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >>> >> ********************************* >> This message and any attachments (the "message") are >> confidential and intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if >> altered, changed or falsified. >> If you are not the intended addressee of this message, please >> cancel it immediately and inform the sender. >> ******************************** >> >> > > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From bruno.chatras@orange-ftgroup.com Tue Jan 26 09:24:07 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9E53A67F4 for ; Tue, 26 Jan 2010 09:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 aqPCetJ7K2-0 for ; Tue, 26 Jan 2010 09:24:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id EF3103A67CC for ; Tue, 26 Jan 2010 09:24:05 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id CEA842AC813; Tue, 26 Jan 2010 18:24:15 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B4FC7384073; Tue, 26 Jan 2010 18:24:15 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:24:15 +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, 26 Jan 2010 18:24:14 +0100 Message-ID: <20708_1264526655_4B5F253F_20708_126737_1_9ECCF01B52E7AB408A7EB8535264214101053776@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4B5F2223.1020407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqeqpREhxH0Ie6aQNCFhbiKMXF4+QAAZslg References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> <09B7DBFE70A9E24BBB21689DAD3A06141C40F1FF@zcarhxm1.corp.nortel.com> <12909_1264521206_4B5F0FF6_12909_64141_1_9ECCF01B52E7AB408A7EB85352642141010535FE@ftrdmel0.rd.francetelecom.fr> <4B5F2223.1020407@cisco.com> From: To: X-OriginalArrivalTime: 26 Jan 2010 17:24:15.0868 (UTC) FILETIME=[62907BC0:01CA9EAC] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.164217 Cc: martini@ietf.org, HKaplan@acmepacket.com Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:24:07 -0000 I thought someone said it needs to be extended along the lines of what was = proposed for the PUBLISH method but I may have overinterpreted one of the p= revious messages. > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : mardi 26 janvier 2010 18:11 > =C0 : CHATRAS Bruno RD-CORE-ISS > Cc : blindsay@nortel.com; HKaplan@acmepacket.com; martini@ietf.org > Objet : Re: [martini] Listing the implicitly registered AoR's >=20 >=20 >=20 > bruno.chatras@orange-ftgroup.com wrote: > > Then we could ask whether there are other SIP-based=20 > architectures that would require the list of implictly=20 > registered identities to be conveyed from the registrar to=20 > the edge proxy. If the answer if no and the use of=20 > P-Associated-URI is not deprecated in IMS-based networks, I'm=20 > not sure it's worth extending the reg-event event package. >=20 > Why would the reg event package need to be extended? >=20 > Paul >=20 > >> -----Message d'origine----- > >> De : Brian Lindsay [mailto:blindsay@nortel.com] Envoy=E9 : mardi 26=20 > >> janvier 2010 16:48 =C0 : CHATRAS Bruno RD-CORE-ISS;=20 > >> HKaplan@acmepacket.com; martini@ietf.org Objet : RE: [martini]=20 > >> Listing the implicitly registered AoR's > >> > >> Hi, > >> > >> I think that's fine. We just don't need to bring the requirement=20 > >> into the Martini draft. Such systems may have incremental=20 > >> requirements above/beyond Martini. > >> > >> -----Original Message----- > >> From: bruno.chatras@orange-ftgroup.com=20 > >> [mailto:bruno.chatras@orange-ftgroup.com] > >> Sent: Tuesday, January 26, 2010 10:45 AM > >> To: HKaplan@acmepacket.com; Lindsay, Brian (CAR:AR00);=20 > >> martini@ietf.org > >> Subject: RE: [martini] Listing the implicitly registered AoR's > >> > >> I assume that IMS-based networks would continue to use=20 > >> P-Associated-URI in their "closed" environnements rather=20 > than use an=20 > >> extended reg-event package. I'v not seen any proposal to deprecate=20 > >> RFC3455 anyway... > >> > >>> -----Message d'origine----- > >>> De : martini-bounces@ietf.org > >>> [mailto:martini-bounces@ietf.org] De la part de Hadriel > >> Kaplan Envoy=E9 > >>> : mardi 26 janvier 2010 16:34 =C0 : Brian Lindsay; martini@ietf.org= =20 > >>> Objet : Re: [martini] Listing the implicitly registered AoR's > >>> > >>> > >>> Hi Brian, > >>> I _think_ that's consistent with using reg-event, because > >> we wouldn't > >>> document a requirement to use reg-event, just note that=20 > it could be=20 > >>> used for that purpose (if even that). > >>> > >>> -hadriel > >>> > >>>> -----Original Message----- > >>>> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On > >>>> Behalf Of Brian Lindsay > >>>> Sent: Tuesday, January 26, 2010 10:15 AM > >>>> To: Hadriel Kaplan; martini@ietf.org > >>>> Subject: Re: [martini] Listing the implicitly registered AoR's > >>>> > >>>> Hi Hadriel, > >>>> > >>>> I don't think this needs to be spelled out in the draft.=20 > >>> There may > >>>> be specific solutions/architectures like IMS that would use > >>> this, and > >>>> that's OK, but I don't believe this is central to the=20 > >>>> mechanism/interface in the draft. > >>>> > >>>> Thanks > >>>> Brian > >>>> > >>>> -----Original Message----- > >>>> From: martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] On > >>>> Behalf Of Hadriel Kaplan > >>>> Sent: Tuesday, January 26, 2010 10:02 AM > >>>> To: martini@ietf.org > >>>> Subject: [martini] Listing the implicitly registered AoR's > >>>> > >>>> On the topic of listing implicitly registered AoR's (what > >> has been > >>>> done so far in P-Associated-URI), the emails on this seem > >>> to focus on > >>>> either requiring it, or not at all. But there was a=20 > third option=20 > >>>> proposed by someone on the last virtual meeting call: use > >>> reg-event for that. > >>>> In other words, don't put them in a PAU/whatever of the > >> REGISTER (or > >>>> PUBLISH) request or response. Instead, use the subscription for=20 > >>>> reg-event to list them. In the P-CSCF/edge-proxy case, the > >>> edge-proxy > >>>> itself can subscribe to that package after the IP-PBX has > >>> registered > >>>> itself. > >>>> > >>>> That seemed like a good compromise to me. (I preferred > >> having it in > >>>> the REGISTER response, but we can't have everything :) > >>>> > >>>> -hadriel > >>>> _______________________________________________ > >>>> martini mailing list > >>>> martini@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/martini > >>>> _______________________________________________ > >>>> martini mailing list > >>>> martini@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/martini > >>> _______________________________________________ > >>> martini mailing list > >>> martini@ietf.org > >>> https://www.ietf.org/mailman/listinfo/martini > >>> > >> ********************************* > >> This message and any attachments (the "message") are=20 > confidential and=20 > >> intended solely for the addressees. > >> Any unauthorised use or dissemination is prohibited. > >> Messages are susceptible to alteration.=20 > >> France Telecom Group shall not be liable for the message=20 > if altered,=20 > >> changed or falsified. > >> If you are not the intended addressee of this message,=20 > please cancel=20 > >> it immediately and inform the sender. > >> ******************************** > >> > >> > >=20 > > ********************************* > > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration.=20 > > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > > If you are not the intended addressee of this message,=20 > please cancel it immediately and inform the sender. > > ******************************** > >=20 > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Tue Jan 26 09:25:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B81D3A6817 for ; Tue, 26 Jan 2010 09:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 V9YDPS-U6w8G for ; Tue, 26 Jan 2010 09:25:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 9C1AF3A67CC for ; Tue, 26 Jan 2010 09:25:43 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EE6B410442F; Tue, 26 Jan 2010 18:25:52 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D1F0E238071; Tue, 26 Jan 2010 18:25:52 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:25:51 +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, 26 Jan 2010 18:25:51 +0100 Message-ID: <4745_1264526752_4B5F25A0_4745_1735_1_9ECCF01B52E7AB408A7EB8535264214101053779@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: AcqeonQ8ma6q1iDrT7SKw53D4lQbmgAAuepgAAHK5fA= References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> From: To: , , , X-OriginalArrivalTime: 26 Jan 2010 17:25:51.0512 (UTC) FILETIME=[9B929980:01CA9EAC] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.15.63321 Cc: martini@ietf.org Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:25:45 -0000 It's probably obvious from what I said before but I vote option-1 as well.= =20 > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : mardi 26 janvier 2010 17:44 > =C0 : Spencer Dawkins; CHATRAS Bruno RD-CORE-ISS;=20 > john.elwell@siemens-enterprise.com; adam@nostrum.com > Cc : martini@ietf.org > Objet : RE: [martini] Enumerating AORs/contacts >=20 >=20 > Well of course they can - and they can do it right now too.=20=20 > So what? As long as we don't advocate it or rely on it. And=20 > we *don't* rely on it. Who's to say the request can't go=20 > direct to the Enterprise? It's a local policy decision if=20 > the Enterprise wants to accept it, of course, but as far as=20 > Martini is concerned it can. >=20 > The question is if a UA in SSP's domain sends a request to=20 > sip:foobar@PBX.com through its SSP proxy-registrar, what=20 > should the SSP proxy-registrar do with the req-uri? > Option-1: leave it alone but insert the registered=20 > path/contact info as Route-header URIs > Option-2: replace it with some form of the registered contact-URI >=20 > I vote option-1. >=20 > The second problem is what if the SSP gets=20 > sip:foobar@SSP.com, and I propose that it retarget it, and=20 > also insert the Route list of the path/contact (because after=20 > retargeting it would then follow Option-1 above again). >=20 > The question is if the retargeting function details should be=20 > prescribed by a SIP-Forum document, or by an IETF document,=20 > or prescribed by the IP-PBX in its registration through some=20 > body list/regex-formula, or left to random implementations. >=20 > -hadriel >=20 >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@wonderhamster.org] > > Sent: Tuesday, January 26, 2010 11:13 AM > > To: Hadriel Kaplan; bruno.chatras@orange-ftgroup.com;=20 > > john.elwell@siemens- enterprise.com; adam@nostrum.com > > Cc: martini@ietf.org > > Subject: Re: [martini] Enumerating AORs/contacts > >=20 > > Hi, Hadriel, > >=20 > > Sorry for being imprecise. "unless the service provider dorks with=20 > > two- faced DNS" - that's the "we" I meant. > >=20 > > And I'm not suggesting that service providers dork with=20 > two-faced DNS=20 > > - just that it's one of the alternatives I can imagine someone=20 > > implementing quickly as a shortcut. > >=20 > > Thanks, > >=20 > > Spencer > >=20 > > ------------------------ > >=20 > > > The problem with user@enterprise.com is that requests=20 > from outside=20 > > > the service provider to this AOR would go straight to the SIP-PBX=20 > > > without traversing any service provider proxy - unless we=20 > dork with=20 > > > two-faced > > DNS, > > > etc. > >=20 > > *We* (martini) won't be dorking with anything. How a=20 > request got to=20 > > the SSP is effectively out of scope for this WG, right? For all I=20 > > know, the request originated in the SSP. The question isn't how it=20 > > got to the SSP - the question is what the SSP should do=20 > about it once=20 > > it gets it. :) > >=20 > > -hadriel >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Tue Jan 26 09:29:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADCC3A6809 for ; Tue, 26 Jan 2010 09:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 jCmUg78uE8s0 for ; Tue, 26 Jan 2010 09:29:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 8DE203A67DB for ; Tue, 26 Jan 2010 09:29:29 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 73D571B8722; Tue, 26 Jan 2010 18:29:39 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 5B621384073; Tue, 26 Jan 2010 18:29:39 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Jan 2010 18:29:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 18:29:37 +0100 Message-ID: <20708_1264526979_4B5F2683_20708_127062_1_9ECCF01B52E7AB408A7EB8535264214101053784@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Requirements - rev2 Thread-Index: Acqep7HmUhBY/O9/ReqmULSNGWiDSAABQhzQ References: <4B5DD8D3.5050705@cisco.com><4B5DF966.1040408@nostrum.com> <4B5DFE8B.1060602@cisco.com> <935A678AA07147B2A4CE062E069F5BBB@china.huawei.com> <4B5E2C00.4050407@cisco.com><778F1105-86AE-4999-8B15-F59C2E5C7EAA@softarmor.com><4B5F18C2.1050305@shockey.us> From: To: , X-OriginalArrivalTime: 26 Jan 2010 17:29:38.0040 (UTC) FILETIME=[22980780:01CA9EAD] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.26.170039 Cc: martini@ietf.org Subject: Re: [martini] Requirements - rev2 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 17:29:30 -0000 To me it would be a pity if the agreed solution was working exclusively for= E.164 numbers. This would mean that a separate solution would have to be u= sed for email-style URI as well as for private numbers since these are not = E.164 numbers and cannot always be converted into an E.164 number. > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > Envoy=E9 : mardi 26 janvier 2010 17:50 > =C0 : Richard Shockey > Cc : martini@ietf.org > Objet : Re: [martini] Requirements - rev2 >=20 >=20 > On Jan 26, 2010, at 10:30 AM, Richard Shockey wrote: >=20 > > > > Dean ...typically the business context for MARTINI is almost=20 > > exclusively E.164 naming where the SSP is in direct=20 > ownership/ control=20 > > of the Layer 1 connection. > > > > And yes .. I need to respond to Paul on the issues with=20 > assuming block=20 > > number routing. This will become increasingly relevant as LNP rolls=20 > > out in the EC. >=20 > Well, if we're willing to constrain our solution to E.164,=20 > then it can be a whole heck of a lot simpler. >=20 > Or we could do a solution NOW that works for the E.164=20 > restriction, and put off solving the general domain routing=20 > problem for phase 2. >=20 > I'd be willing to entertain a solution that is only applicable to E.=20 > 164. Do we want to do it this way? >=20 > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From drage@alcatel-lucent.com Tue Jan 26 10:20:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D543A685E for ; Tue, 26 Jan 2010 10:20:26 -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_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 fTmWWzM7sANW for ; Tue, 26 Jan 2010 10:20:19 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E0A203A697A for ; Tue, 26 Jan 2010 10:20:18 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o0QIKQJl013369 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Jan 2010 19:20:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 26 Jan 2010 19:20:26 +0100 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange-ftgroup.com" , "HKaplan@acmepacket.com" , "blindsay@nortel.com" , "martini@ietf.org" Date: Tue, 26 Jan 2010 19:20:23 +0100 Thread-Topic: [martini] Listing the implicitly registered AoR's Thread-Index: AcqemHnISq6KhiIrSLme4s5H6Zn0wQAAUZkgAADKxIAAAEjFIAAFdXDA Message-ID: References: <09B7DBFE70A9E24BBB21689DAD3A06141C3C89E5@zcarhxm1.corp.nortel.com> <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <27426_1264520683_4B5F0DEB_27426_17239_1_9ECCF01B52E7AB408A7EB85352642141010535DA@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [martini] Listing the implicitly registered AoR's X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:20:26 -0000 IMS supports both reg event and P-Associated-URI. They convey different thi= ngs about what is registered. RFC 4083 spells out some of that in terms of IETF terminology. Specifically, IMS can deregister AORs based on SSP specific conditions. The= only way that the attached entity can find out that information is using r= eg event.=20 regards Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Tuesday, January 26, 2010 3:45 PM > To: HKaplan@acmepacket.com; blindsay@nortel.com; martini@ietf.org > Subject: Re: [martini] Listing the implicitly registered AoR's >=20 > I assume that IMS-based networks would continue to use=20 > P-Associated-URI in their "closed" environnements rather than=20 > use an extended reg-event package. I'v not seen any proposal=20 > to deprecate RFC3455 anyway... >=20 > > -----Message d'origine----- > > De : martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] De la part de Hadriel=20 > Kaplan Envoy=E9=20 > > : mardi 26 janvier 2010 16:34 =C0 : Brian Lindsay; martini@ietf.org=20 > > Objet : Re: [martini] Listing the implicitly registered AoR's > >=20 > >=20 > > Hi Brian, > > I _think_ that's consistent with using reg-event, because=20 > we wouldn't=20 > > document a requirement to use reg-event, just note that it could be=20 > > used for that purpose (if even that). > >=20 > > -hadriel > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > > > Behalf Of Brian Lindsay > > > Sent: Tuesday, January 26, 2010 10:15 AM > > > To: Hadriel Kaplan; martini@ietf.org > > > Subject: Re: [martini] Listing the implicitly registered AoR's > > >=20 > > > Hi Hadriel, > > >=20 > > > I don't think this needs to be spelled out in the draft.=20 > > There may > > > be specific solutions/architectures like IMS that would use > > this, and > > > that's OK, but I don't believe this is central to the=20 > > > mechanism/interface in the draft. > > >=20 > > > Thanks > > > Brian > > >=20 > > > -----Original Message----- > > > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > > > Behalf Of Hadriel Kaplan > > > Sent: Tuesday, January 26, 2010 10:02 AM > > > To: martini@ietf.org > > > Subject: [martini] Listing the implicitly registered AoR's > > >=20 > > > On the topic of listing implicitly registered AoR's (what=20 > has been=20 > > > done so far in P-Associated-URI), the emails on this seem > > to focus on > > > either requiring it, or not at all. But there was a third option=20 > > > proposed by someone on the last virtual meeting call: use > > reg-event for that. > > >=20 > > > In other words, don't put them in a PAU/whatever of the=20 > REGISTER (or > > > PUBLISH) request or response. Instead, use the subscription for=20 > > > reg-event to list them. In the P-CSCF/edge-proxy case, the > > edge-proxy > > > itself can subscribe to that package after the IP-PBX has > > registered > > > itself. > > >=20 > > > That seemed like a good compromise to me. (I preferred=20 > having it in=20 > > > the REGISTER response, but we can't have everything :) > > >=20 > > > -hadriel > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > > > martini mailing list > > > martini@ietf.org > > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > >=20 >=20 > ********************************* > This message and any attachments (the "message") are=20 > confidential and intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if=20 > altered, changed or falsified. > If you are not the intended addressee of this message, please=20 > cancel it immediately and inform the sender. > ******************************** >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From spencer@wonderhamster.org Tue Jan 26 12:05:43 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B464B3A69A7 for ; Tue, 26 Jan 2010 12:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyxbxW-BMzOc for ; Tue, 26 Jan 2010 12:05:39 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A6CEA3A689C for ; Tue, 26 Jan 2010 12:05:39 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MOwKl-1NTYfa3WFD-006KDW; Tue, 26 Jan 2010 15:05:43 -0500 Message-ID: <3A58F7D634A640988A737AEA917DFB93@china.huawei.com> From: "Spencer Dawkins" To: Date: Tue, 26 Jan 2010 14:05:34 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CA9E90.A0E26030" 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: V01U2FsdGVkX182WR4JIj7uxM24EdJtUr7YyUAoToGTlmx197I 2BwEd5l77xuFQ/o6zm6B0lYZCi6XzRBSuxJRD/XiqvMOPKhpHy vOsRdbv9ZoYqFuYA031PoyTDpul+rRUfURfR9eAkr8= Subject: [martini] Fw: Your recording "MARTINI WG Virtual Meeting-20100126 1659-1" is available for viewing X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 20:05:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01CA9E90.A0E26030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just for people who need to check what other people said on the telechat = today... Spencer ----- Original Message -----=20 From: Alexa Morris=20 To: Spencer Dawkins=20 Sent: Tuesday, January 26, 2010 1:58 PM Subject: Fwd: Your recording "MARTINI WG Virtual Meeting-20100126 = 1659-1" is available for viewing Begin forwarded message: From: messenger@webex.com Date: January 26, 2010 11:52:37 AM PST To: amorris@amsl.com Subject: Your recording "MARTINI WG Virtual Meeting-20100126 1659-1" = is available for viewing Reply-To: messenger@webex.com IETF Secretariat,=20 Your recording is now available on the WebEx service site. Click the = link below to play it:=20 = https://workgreen.webex.com/workgreen/lsr.php?AT=3Dpb&SP=3DMC&rID=3D37083= 47&rKey=3Dc590fccd9c0dabe3=20 MARTINI WG Virtual Meeting-20100126 1659-1=20 Tuesday, January 26, 2010 10:59 am Chicago Time=20 2 Hours 47 Minutes=20 * You can forward this message to others to allow them to play back = the recording. *=20 -------------------------------------=20 Additional Options=20 -------------------------------------=20 To edit recording information and playback control options, click the = link below:=20 https://workgreen.webex.com/workgreen/editrd.php?rID=3D3708347&SP=3DMC = To view more options for this recording, such as downloading, click = the link below:=20 https://workgreen.webex.com/workgreen/viewrd.php?rID=3D3708347&SP=3DMC = To view all your WebEx Meeting Center recordings, click the link = below:=20 https://workgreen.webex.com/workgreen/servicerds.php?SP=3DMC=20 http://www.webex.com=20 ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com ------=_NextPart_000_002B_01CA9E90.A0E26030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just for people who need to check what other people = said on=20 the telechat today...
 
Spencer
 
----- Original Message -----=20
From: Alexa = Morris
Sent: Tuesday, January 26, 2010 1:58 PM
Subject: Fwd: Your recording "MARTINI WG Virtual = Meeting-20100126=20 1659-1" is available for viewing



Begin forwarded message:

From: messenger@webex.com
Date: January 26, = 2010 11:52:37=20 AM PST
To: amorris@amsl.com
Subject: Your = recording "MARTINI=20 WG Virtual Meeting-20100126 1659-1" is available for = viewing
Reply-To: = messenger@webex.com

IETF = Secretariat,=20

Your recording is now available on the WebEx service site. = Click the=20 link below to play it:

https://workgreen.webex.com/workgreen/lsr.php?AT=3Dpb&= ;SP=3DMC&rID=3D3708347&rKey=3Dc590fccd9c0dabe3=20

MARTINI WG Virtual Meeting-20100126 1659-1
Tuesday, = January 26,=20 2010 10:59 am Chicago Time
2 Hours 47 Minutes

* You can = forward=20 this message to others to allow them to play back the recording. *=20

-------------------------------------
Additional Options=20
-------------------------------------

To edit recording=20 information and playback control options, click the link below:
https://workgreen.webex.com/workgreen/editrd.php?rID=3D37= 08347&SP=3DMC=20

To view more options for this recording, such as downloading, = click=20 the link below:
https://workgreen.webex.com/workgreen/viewrd.php?rID=3D37= 08347&SP=3DMC=20

To view all your WebEx Meeting Center recordings, click the = link=20 below:
https://workgreen.webex.com/workgreen/servicerds.php?SP=3D= MC=20

http://www.webex.com=20

-----------
Alexa Morris / Executive Director / IETF
48377 = Fremont=20 Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / = Fax:=20 +1.510.492.4001
Email: amorris@amsl.com

Managed by=20 Association Management Solutions (AMS)
Forum Management, Meeting and = Event=20 Planning
www.amsl.com <http://www.amsl.com/>

------=_NextPart_000_002B_01CA9E90.A0E26030-- From fluffy@cisco.com Tue Jan 26 19:46:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F0E3A681D for ; Tue, 26 Jan 2010 19:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.31 X-Spam-Level: X-Spam-Status: No, score=-110.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ21UQc3TwHW for ; Tue, 26 Jan 2010 19:46:26 -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 EAEED3A659B for ; Tue, 26 Jan 2010 19:46:25 -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: ApoEAE5GX0urR7Ht/2dsb2JhbADCXJcmgjOCBAQ X-IronPort-AV: E=Sophos;i="4.49,350,1262563200"; d="scan'208";a="140564474" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2010 03:46:38 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0R3kbPe016769; Wed, 27 Jan 2010 03:46:37 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 26 Jan 2010 20:46:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1077) Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 03:46:26 -0000 On Jan 26, 2010, at 9:47 AM, DRAGE, Keith (Keith) wrote: > I've just read my way through this entire thread again. >=20 > So going back to the start, what IMS does is mechanism 1), not 3). I'm not really sure it makes much difference for deciding what to do = here, but when I look at 3GPP R5, it looks to me very much that the SSP = was responsible for the domain and not the terminal. Part of the point = of IMS was the service provider, not the terminal, being able to create = and control services. So I come to a very different conclusion about if = it is 1 or 3. Now I'd be the first to say than Keith understands 3GPP = better than I ever will but I'm just not understanding how you come to = the conclusion that the service provider was not responsible, in the = 3261 sense of responsible, for the AOR.=20 >=20 > If does this on the basis that we are trying to simulate as much as = possible what a proxy doing an ordinary DNS look up would do. However it = includes the extra Route header value because it needs to get through = the rest of the IMS proxies to the gateway PBX. >=20 > As such any issues probably exist in the straight network peering = solution as well. I would make the following points: >=20 > 1) Dean quite rightly stated that the enterprise operator is = devolving some responsibility to the SSP. In TISPAN/3GPP, the view is = essentially that the SSP is providing some form of virtual transit PBX, = which the SSP rents to the enterprise provider.So the devolving of DNS = responsibility is on the basis of that. >=20 > 2) The number routing problem is no different to that that exists = between two SSPs. If you are a user with 123 @ ssp_example1 and I make a = call to 123 @ ssp_example2, what does ssp_example2 do with this call. = Either it ignores the domain name and processes it anyway - something = that is not allowed by IETF but many operators do anyway, or it rejects = the call. I don't expect anything different to happen in the business = trunking. Thus the correct address for users on the PBX is = number@pbx.com, not number@ssp.com. How the SSP handlesnumber@ssp.com is = not going to alter based on an IETF edict, but it will be the SSP = breaking the rules. >=20 > regards >=20 > Keith Cullen From dean.willis@softarmor.com Tue Jan 26 22:16:21 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93483A6784 for ; Tue, 26 Jan 2010 22:16:20 -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 CXJxMgr2cUAy for ; Tue, 26 Jan 2010 22:16:14 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 387B53A687F for ; Tue, 26 Jan 2010 22:16:14 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0R6GPxT023858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jan 2010 00:16:26 -0600 Message-Id: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> From: Dean Willis To: martini@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, 27 Jan 2010 00:16:19 -0600 X-Mailer: Apple Mail (2.936) Subject: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 06:16:21 -0000 We seem to have an urgent need for a near-term solution for dealing with the subset of the MARTINI problem that, loosely defined, covers the "telephone number" problem. The typical scenario here is SIP trunking, wherein a SIP Service Provider (SSP) provides an ISDN-PRI like service over IP to a customer's PBX (or PBXes). In this model, the SSP maps a whole bunch of phone numbers to the PBXes. This mapping is somewhat dynamic, because the PBXes usually have DHCP addresses, and don't have DNS entries that point A records at the PBX in any sort of particularly useful way (maybe something like dhcp-10-1-2-3-example.com). So what we need is a way for a PBX, when it reboots (or perhaps periodically) to say to the SSP "Here I Am; You may now send any calls for my assigned phone numbers to my current Contact." This is indeed a "registration" problem, but it isn't necessarily a "domain registration problem". The only reason domains get mixed into this scenario at all is that we sometimes encode telephone numbers as the user parts of SIP URIs, and those SIP URIs have a domain part attached to them. More interestingly, this problem is a tiny subset of the whole MARTINI dynamic binding problem, and it potentially can be solved much more simply than the general problem. On today's Interim II call, Richard, Adam and I raised the idea of dividing our problem space, and taking on a near-term milestone for delivering a MARTINI solution for registering contacts to a proxy, where that proxy maps one or more telephone numbers to the contact. We certainly intend to go on and tackle the more general domain- registration problem, but I (and I believe Adam and Richard) believe that we get a lot out of tackling the telephone-number subset first. In particular, we believe that this approach solves many of the domain "responsibility" questions, simplifies the TLS keying/certification model immensely, eliminates the cognitive overload of using REGISTER to bind a "domain" to a Contact, "route authentication", and a good many other open issues that plague our current drafts. Open questions relating to this approach include: 1) Do we deal only with E.164 numbers, or do we need to deal with private-number "phone contexts"? 2) D owe need to explicitly encode the telephone numbers being registered in the REGISTER request (either directly or through some sort of regexp), or is it adequate to rely on provisioning of the SSP and PBX (and any UAs) to statically bind the numbers to the PBX identity, and then dynamically only register the PBX identity to the PBX contact? 3) Can we "register" with a tel: URI as the "To" value? (this seems to require extending RFC 3261)? Note that "tel:" can express both E.164 numbers and private phone-contexts in one format. 4) What happens with GRUUs? I believe all of these issues are quite tractable, if we accept the fundamental idea of splitting the phone-number problem off from the more general domain-registration, and recognize the possibility that the solutions to the two problem may reasonably be quite different from each other. So, what do you people think? Is it worth trying to drink the MARTINI elephant one sip at a time, or are we going to treat the whole thing like a tequila shot and just slam it down? -- Dean From sanjsinh@cisco.com Tue Jan 26 22:38:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935253A6852 for ; Tue, 26 Jan 2010 22:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eo5W8BbaRos for ; Tue, 26 Jan 2010 22:38:23 -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 CDDBC3A67D8 for ; Tue, 26 Jan 2010 22:38:22 -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: ApoEAKBtX0utJV2b/2dsb2JhbADBbolWAY1hgi4NgX0EjhE X-IronPort-AV: E=Sophos;i="4.49,351,1262563200"; d="scan'208";a="292734532" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2010 06:38:35 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0R6cZRV007467; Wed, 27 Jan 2010 06:38:35 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 00:38: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, 27 Jan 2010 00:38:32 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CAA873FC@XMB-RCD-101.cisco.com> In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqfGEo4yx4veFQpTlWde94+Teea4AAAePcw References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> From: "Sanjay Sinha (sanjsinh)" To: "Dean Willis" , X-OriginalArrivalTime: 27 Jan 2010 06:38:35.0325 (UTC) FILETIME=[59D07ED0:01CA9F1B] Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 06:38:24 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Wednesday, January 27, 2010 11:46 AM > To: martini@ietf.org > Subject: [martini] Proposed work split: tackle telephone-number registrationfirst >=20 >=20 > We seem to have an urgent need for a near-term solution for dealing > with the subset of the MARTINI problem that, loosely defined, covers > the "telephone number" problem. >=20 > The typical scenario here is SIP trunking, wherein a SIP Service > Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's PBX (or PBXes). In this model, the SSP maps a whole bunch > of phone numbers to the PBXes. This mapping is somewhat dynamic, > because the PBXes usually have DHCP addresses, and don't have DNS > entries that point A records at the PBX in any sort of particularly > useful way (maybe something like dhcp-10-1-2-3-example.com). >=20 > So what we need is a way for a PBX, when it reboots (or perhaps > periodically) to say to the SSP "Here I Am; You may now send any calls > for my assigned phone numbers to my current Contact." >=20 > This is indeed a "registration" problem, but it isn't necessarily a > "domain registration problem". The only reason domains get mixed into > this scenario at all is that we sometimes encode telephone numbers as > the user parts of SIP URIs, and those SIP URIs have a domain part > attached to them. >=20 > More interestingly, this problem is a tiny subset of the whole MARTINI > dynamic binding problem, and it potentially can be solved much more > simply than the general problem. >=20 > On today's Interim II call, Richard, Adam and I raised the idea of > dividing our problem space, and taking on a near-term milestone for > delivering a MARTINI solution for registering contacts to a proxy, > where that proxy maps one or more telephone numbers to the contact. >=20 > We certainly intend to go on and tackle the more general domain- > registration problem, but I (and I believe Adam and Richard) believe > that we get a lot out of tackling the telephone-number subset first. >=20 > In particular, we believe that this approach solves many of the domain > "responsibility" questions, simplifies the TLS keying/certification > model immensely, eliminates the cognitive overload of using REGISTER > to bind a "domain" to a Contact, "route authentication", and a good > many other open issues that plague our current drafts. >=20 >=20 > Open questions relating to this approach include: >=20 > 1) Do we deal only with E.164 numbers, or do we need to deal with > private-number "phone contexts"? For call between different administrative domains, I think having a normative statement about E.164 numbers only or following RFC 3966 syntax, will make life much simpler. Sanjay >=20 > 2) D owe need to explicitly encode the telephone numbers being > registered in the REGISTER request (either directly or through some > sort of regexp), or is it adequate to rely on provisioning of the SSP > and PBX (and any UAs) to statically bind the numbers to the PBX > identity, and then dynamically only register the PBX identity to the > PBX contact? >=20 > 3) Can we "register" with a tel: URI as the "To" value? (this seems to > require extending RFC 3261)? Note that "tel:" can express both E.164 > numbers and private phone-contexts in one format. >=20 > 4) What happens with GRUUs? >=20 > I believe all of these issues are quite tractable, if we accept the > fundamental idea of splitting the phone-number problem off from the > more general domain-registration, and recognize the possibility that > the solutions to the two problem may reasonably be quite different > from each other. >=20 > So, what do you people think? Is it worth trying to drink the MARTINI > elephant one sip at a time, or are we going to treat the whole thing > like a tequila shot and just slam it down? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From john.elwell@siemens-enterprise.com Wed Jan 27 01:07:48 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58DA3A691F for ; Wed, 27 Jan 2010 01:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 B4INQRD9B41p for ; Wed, 27 Jan 2010 01:07:47 -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 973663A676A for ; Wed, 27 Jan 2010 01:07:47 -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-679348; Wed, 27 Jan 2010 10:08:00 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 22CED1EB82AB; Wed, 27 Jan 2010 10:08:00 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Jan 2010 10:07:59 +0100 From: "Elwell, John" To: Hadriel Kaplan , Adam Roach Date: Wed, 27 Jan 2010 10:07:58 +0100 Thread-Topic: [martini] The much maligned Request-URI Thread-Index: AcqeoWBhwNSKhv+rRaqy/FdXIeowiwAAuzJwACLmMdA= Message-ID: References: <4B5F0C9B.1010908@nostrum.com> <4B5F0EFF.6010800@nostrum.com> <4B5F12B3.5020701@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] The much maligned Request-URI X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 09:07:49 -0000 I think Hadriel makes an excellent point here. The SSP somehow has a reques= t for pbx.com, and needs to know how to route it there, in the absence of b= eing able to use RFC 3263. How the SSP gets that request can be considered = out of scope. John=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 26 January 2010 16:34 > To: Adam Roach > Cc: martini@ietf.org > Subject: Re: [martini] The much maligned Request-URI >=20 > I'm not proposing a solution that ignores DNS wholesale. I'm=20 > proposing a mechanism for routing a request from domain-A=20 > (e.g., an SSP) to domain-B (e.g. a IP-PBX), for cases where=20 > DNS cannot be used for reaching domain-B from domain-A. How=20 > a request gets to domain-A is not a problem for Martini. If=20 > someone chooses to provision DNS such that domain-B has an=20 > entry which points to domain-A, that's their issue and I'm=20 > neither condoning it nor mentioning it. I can't stop people=20 > from having host files or local policy overrides either.=20 >=20 > =20 >=20 > -hadriel >=20 > =20 >=20 > ________________________________ >=20 > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Tuesday, January 26, 2010 11:05 AM > To: Hadriel Kaplan > Cc: martini@ietf.org > Subject: Re: [martini] The much maligned Request-URI >=20 > =20 >=20 > On 1/26/10 10:00, Jan 26, Hadriel Kaplan wrote:=20 >=20 > Not at all - I have no idea what Braniff would want to do=20 > (probably use adam@verizon.com, since Verizon now owns=20 > Braniff's former headquarters building J). >=20 > But seriously, how a request to adam@braniff.com happened to=20 > get to centricvoice's proxies does not matter... >=20 >=20 > It kind of does. If you're proposing a solution that is=20 > predicated on ignoring DNS wholesale, then you've just=20 > amplified the alt-root problem by several orders of magnitude. >=20 > The answer to that question must be "it works AT LEAST for=20 > the cases in which RFC 3263 routing procedures took it to the=20 > SSP". If you want to make it work for other scenarios, that's=20 > fine. But if you're designing a solution that cannot work on=20 > the Internet at large, then it really won't fly. >=20 > /a >=20 > = From john.elwell@siemens-enterprise.com Wed Jan 27 01:08:17 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC133A6A2A for ; Wed, 27 Jan 2010 01:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Fa9gIkeqsFJ8 for ; Wed, 27 Jan 2010 01:08:16 -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 3025F3A676A for ; Wed, 27 Jan 2010 01:08:16 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-679360; Wed, 27 Jan 2010 10:08:25 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2294423F028E; Wed, 27 Jan 2010 10:08:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Jan 2010 10:08:24 +0100 From: "Elwell, John" To: Hadriel Kaplan , Adam Roach Date: Wed, 27 Jan 2010 10:08:23 +0100 Thread-Topic: [martini] Enumerating AORs/contacts Thread-Index: Acqep6aOmmDRJojgQ1asqMB/bgbKXQAAGa0gACEp3VA= Message-ID: References: <25818_1264499404_4B5EBACC_25818_434_1_9ECCF01B52E7AB408A7EB853526421410101ADCF@ftrdmel0.rd.francetelecom.fr> <4B5F1D4C.6080301@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Enumerating AORs/contacts X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 09:08:17 -0000 =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 26 January 2010 16:59 > To: Adam Roach > Cc: Spencer Dawkins; bruno.chatras@orange-ftgroup.com;=20 > Elwell, John; martini@ietf.org > Subject: RE: [martini] Enumerating AORs/contacts >=20 >=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: Tuesday, January 26, 2010 11:50 AM > > To: Hadriel Kaplan > > Cc: Spencer Dawkins; bruno.chatras@orange-ftgroup.com; > > john.elwell@siemens-enterprise.com; martini@ietf.org > > Subject: Re: [martini] Enumerating AORs/contacts > >=20 > > On 1/26/10 10:43, Jan 26, Hadriel Kaplan wrote: > > > The question is if a UA in SSP's domain sends a request to > > sip:foobar@PBX.com through its SSP proxy-registrar, what=20 > should the SSP > > proxy-registrar do with the req-uri? > > > Option-1: leave it alone but insert the registered=20 > path/contact info as > > Route-header URIs > > > Option-2: replace it with some form of the registered contact-URI > > > > > > I vote option-1. > > > > >=20 > > And I could kind of see where this was coming from, if we were using > > something other than REGISTER to define this routing=20 > information. But > > the type of operation you describe in option-1 has never=20 > been associated > > with REGISTER. The thing you're describing in option-1 is=20 > effectively a > > site-local DNS override, not an AOR =3D> Contact binding. >=20 > That's why we're talking about a standards-track document and=20 > an options-tag rather than a BCP. :) >=20 > You make it sound like the "REGISTER" method is immutable as=20 > to the logic which a registrar-proxy performs and derives=20 > routing information from its entries. What is so sacrosanct=20 > about a REGISTER that all derivative information cannot be=20 > used for new procedures? Is it covered by GPL 3.0? [JRE] Exactly. We would still be using REGISTER to register a contact and a= path. The difference is just in how that registered information is used to= route a subsequent inbound request. John f >=20 > -hadriel > = From john.elwell@siemens-enterprise.com Wed Jan 27 02:19:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9021F3A68E8 for ; Wed, 27 Jan 2010 02:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z81b5Q08dmfK for ; Wed, 27 Jan 2010 02:19:32 -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 A4CED3A6858 for ; Wed, 27 Jan 2010 02:19:31 -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-680940; Wed, 27 Jan 2010 11:19:43 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id D53661EB82AE; Wed, 27 Jan 2010 11:19:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Jan 2010 11:19:43 +0100 From: "Elwell, John" To: Dean Willis , "martini@ietf.org" Date: Wed, 27 Jan 2010 11:19:42 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-number registration first Thread-Index: AcqfGEopkjdtTBjNSrGe4Weo2mS0lwAGcjWw Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.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: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 10:19:33 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 27 January 2010 06:16 > To: martini@ietf.org > Subject: [martini] Proposed work split: tackle=20 > telephone-number registration first >=20 >=20 > We seem to have an urgent need for a near-term solution for dealing =20 > with the subset of the MARTINI problem that, loosely defined, covers =20 > the "telephone number" problem. >=20 > The typical scenario here is SIP trunking, wherein a SIP Service =20 > Provider (SSP) provides an ISDN-PRI like service over IP to a =20 > customer's PBX (or PBXes). In this model, the SSP maps a=20 > whole bunch =20 > of phone numbers to the PBXes. This mapping is somewhat dynamic, =20 > because the PBXes usually have DHCP addresses, and don't have DNS =20 > entries that point A records at the PBX in any sort of particularly =20 > useful way (maybe something like dhcp-10-1-2-3-example.com). >=20 > So what we need is a way for a PBX, when it reboots (or perhaps =20 > periodically) to say to the SSP "Here I Am; You may now send=20 > any calls =20 > for my assigned phone numbers to my current Contact." >=20 > This is indeed a "registration" problem, but it isn't necessarily a =20 > "domain registration problem". The only reason domains get=20 > mixed into =20 > this scenario at all is that we sometimes encode telephone=20 > numbers as =20 > the user parts of SIP URIs, and those SIP URIs have a domain part =20 > attached to them. >=20 > More interestingly, this problem is a tiny subset of the=20 > whole MARTINI =20 > dynamic binding problem, and it potentially can be solved much more =20 > simply than the general problem. >=20 > On today's Interim II call, Richard, Adam and I raised the idea of =20 > dividing our problem space, and taking on a near-term milestone for =20 > delivering a MARTINI solution for registering contacts to a proxy, =20 > where that proxy maps one or more telephone numbers to the contact. >=20 > We certainly intend to go on and tackle the more general domain-=20 > registration problem, but I (and I believe Adam and Richard) believe =20 > that we get a lot out of tackling the telephone-number subset first. >=20 > In particular, we believe that this approach solves many of=20 > the domain =20 > "responsibility" questions, simplifies the TLS keying/certification =20 > model immensely, eliminates the cognitive overload of using REGISTER =20 > to bind a "domain" to a Contact, "route authentication", and a good =20 > many other open issues that plague our current drafts. [JRE] I indicated on the call that I would be prepared to go along with thi= s approach. However, I did this on the understanding that it would give a s= ufficiently complete approach for the short term, and also on the assumptio= n that it really can be shown to represent a simplification. It is true tha= t what the market needs in the short term is a solution for E.164 numbers, = but we need to be careful about whether or not we can exclude private numbe= rs (I am on the fence on that one) and what would be our solution for call = transfer (which might involve the use of gruus). It could be that in satisf= ying these issues we would end up with a solution that really is not signif= icantly simpler, or could deal with email-style AORs too. So we need to dri= ll down into what really is meant. Thanks, Dean, for kicking this off. The motivation for restricting to AORs based on E.164 numbers was basically= that E.164 numbers are not tied to domains, and the practice of changing t= he domain part of a SIP URI without changing the user part is more palatabl= e. However, Hadriel has recently argued (and found support from some people= ) that this is outside the scope of MARTINI. Either my request starts off b= eing targeted at sip:user@pbx.com and DNS takes it first to the SP (the SP = having delegated responsibility for pbx.com), which then uses MARTINI proce= dures to route to pbx.com. Or my request starts off being targeted at sip:u= ser@sp.com, and on arrival at the SP there is some manipulation of the Requ= est-URI so that it becomes sip:user@pbx.com. It is this manipulation that s= eems to be acceptable for E.164-based AORs but not for others. But, as Hadr= iel points out, MARTINI does not need to cover the issue of how the request= reaches the SP, only the fact that the SP has a request targeted at pbx.co= m and needs a means of routing it there. So in my opinion, motivation for l= imiting to E.164-based AORs is rather weak. Nevertheless, if we can indeed = come up with something simpler by having this limitation, that would be fin= e if we have a suitable story for related issues (private number, call tran= sfer, etc.). By the way, I don't think the fact that numbers are more amenable to regex = is a particularly compelling argument for limiting to numbers. Number porta= bility is fragmenting the number space anyway, and a solution that works on= ly in the absence of major fragmentation would not be acceptable. More below in response to Dean's individual points. >=20 >=20 > Open questions relating to this approach include: >=20 > 1) Do we deal only with E.164 numbers, or do we need to deal with =20 > private-number "phone contexts"? [JRE] We need support for private numbers at some stage. If we can show tha= t a satisfactory solution can be found more easily and quickly for E.164 nu= mbers only, I would accept that. >=20 > 2) D owe need to explicitly encode the telephone numbers being =20 > registered in the REGISTER request (either directly or through some =20 > sort of regexp), or is it adequate to rely on provisioning of=20 > the SSP =20 > and PBX (and any UAs) to statically bind the numbers to the PBX =20 > identity, and then dynamically only register the PBX identity to the =20 > PBX contact? [JRE] It is not necessary to explicitly encode the telephone numbers in the= REGISTER request. If we can use reg-event without modification to obtain t= hat information, that would be fine. If reg-event requires enhancement, or = we need to rely on a provisioning protocol, that should not be allowed to d= elay the basic MARTINI mechanism. >=20 > 3) Can we "register" with a tel: URI as the "To" value? (this=20 > seems to =20 > require extending RFC 3261)? Note that "tel:" can express both E.164 =20 > numbers and private phone-contexts in one format. [JRE]I am not enthusiastic about using tel URIs. I don't see what it would = solve, and it would introduce issues. Unless we still limit it to E.164-bas= ed tel URIs, we would still have the issue of domain-specific AORs. >=20 > 4) What happens with GRUUs? [JRE] I think the fundamental question is what is our story for call transf= er. One possible story would be to rely on 3PCC, so the PBX and SP would no= t send REFER and/or Replaces across the interface. I hear cries of horror, = but in practice this is what happens mostly today. In particular, policy is= sues can make a domain nervous about accepting a REFER request from another= domain. Another possibility would be for the SP to treat contact URIs from the PBX = as local and map to global contact URIs (in its own domain) for passing onw= ards, so that any inbound request to the contact will arrive at the SP and = be mapped back to the local contact URI provided by the PBX. It means the S= P has to operate as a B2BUA. To do the job properly, the PBX needs to issue a gruu (I use lower case her= e, to mean that the contact URI needs to be globally routable, without nece= ssarily implying that the PBX has used GRUU procedures between it and its l= ocal UA). Public gruus can be based on E.164 numbers (they just have a para= meter attached), but temporary gruus cannot be done in this way and effecti= vely are "email-style". If we decide we have to allow the PBX to mint tempo= rary gruus, we lose any benefit of limiting to E.164-based AORs. Besides call transfer, gruus have been suggested in the context of ECRIT, f= or making a call-back to the device that made an emergency call. A mechanis= m whereby the SP maps local contacts to global contacts should work for thi= s too. >=20 > I believe all of these issues are quite tractable, if we accept the =20 > fundamental idea of splitting the phone-number problem off from the =20 > more general domain-registration, and recognize the possibility that =20 > the solutions to the two problem may reasonably be quite different =20 > from each other. >=20 > So, what do you people think? Is it worth trying to drink the=20 > MARTINI =20 > elephant one sip at a time, or are we going to treat the whole thing =20 > like a tequila shot and just slam it down? [JRE] In summary, I am not yet convinced that the problem with non-E.164-ba= sed or non-number-based AORs is intractable or that limiting to E.164-based= or number-based AORs represents a feasible simplification, but I am willin= g to explore further. John >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From dean.willis@softarmor.com Wed Jan 27 08:04:12 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B32403A6A64 for ; Wed, 27 Jan 2010 08:04: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=[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 NxGcDgsNUFkc for ; Wed, 27 Jan 2010 08:04:11 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 49CB73A68C4 for ; Wed, 27 Jan 2010 08:04:11 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0RG4NIA029863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jan 2010 10:04:25 -0600 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 27 Jan 2010 10:04:18 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 16:04:12 -0000 On Jan 27, 2010, at 4:19 AM, Elwell, John wrote: > > > The motivation for restricting to AORs based on E.164 numbers was > basically that E.164 numbers are not tied to domains, and the > practice of changing the domain part of a SIP URI without changing > the user part is more palatable. However, Hadriel has recently > argued (and found support from some people) that this is outside the > scope of MARTINI. Either my request starts off being targeted at sip:user@pbx.com > and DNS takes it first to the SP (the SP having delegated > responsibility for pbx.com), which then uses MARTINI procedures to > route to pbx.com. Or my request starts off being targeted at sip:user@sp.com > , and on arrival at the SP there is some manipulation of the Request- > URI so that it becomes sip:user@pbx.com. It is this manipulation > that seems to be acceptable for E.164-based AORs but not for others. > But, as Hadriel points out, MARTINI does not need to cover the issue > of how the request reaches the SP, only the fact that the SP has a > request targeted at pbx.com and needs a means of routing it there. > So in my opinion, motivation for limiting to E.164-based AORs is > rather weak. Nevertheless, if we can indeed come up with something > simpler by having this limitation, that would be fine if we have a > suitable story for related issues (private number, call transfer, > etc.). Richard sees to be saying that the use case "A call shows up at SSP with a URI of @pbx.com" is out-of-scope for his use case (except POSSIBLY for the result of call transfer). The fundamental SIPConnect use cases, as I understand them, are: 1) A call shows up at an SSP's gateway for some phone number, say "+15125551212". The gateway sends the resulting INVITE to SSP's proxy. How does this proxy know which PBX to send the call to? 2) An INVITE shows up at an SSP's SBC for some phone number, say "+15125551212" that is scoped to the SSP's domain by being "@ssp.com"". The SBC forwards the INVITE to SSP's proxy. How does this proxy know which PBX to send the call to? Where, in the SIPConnect model, does "@pbx.com" come into play? We've suggested that it might do so, if PBX mints and uses a GRUU, and that GRUU is scoped into the domain of "pbx.com". But this is silly; the whole reason for using MARTINI is that "@pbx.com" is either useless, or points to the SSP. So really, what we need to do is have the SSP mint a GRUU, scoped to "@ssp.com", which is then used by PBX in call- transfer scenarios. Is there any other reason to have "@pbx.com" in the current problem scope? Yes, figuring out how to do dynamically-associated relay services for domain-scoped messages is important. But it's a different and completely separable problem (although once solved, we might find that the solution backward-applies to the telephone problem). However, I firmly believe that solving it requires solving some of the fundamental design problems in SIP, such as the fact that our model for registering a multi-hop route is pretty hokey (combining RFC 3261's REGISTER, Service-Route, Path, Outbound, connect-Reuse, and a mess of unimplemented public keys stuff). I think it's gonna be a while before we solve the general dynamically-associated relay services for domain-scoped messages problem. -- Dean From drage@alcatel-lucent.com Wed Jan 27 09:00:36 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A85A3A6828 for ; Wed, 27 Jan 2010 09:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grHiDi5Q8+IF for ; Wed, 27 Jan 2010 09:00:35 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 247883A6816 for ; Wed, 27 Jan 2010 09:00:34 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id o0RH0LPu028718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Jan 2010 18:00:22 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 27 Jan 2010 18:00:21 +0100 From: "DRAGE, Keith (Keith)" To: Cullen Jennings Date: Wed, 27 Jan 2010 18:00:19 +0100 Thread-Topic: [martini] Requirements - rev1 Thread-Index: AcqfA2yWWUn5Vcl4SNq0yESySml7GgAbVxBQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "martini@ietf.org" Subject: Re: [martini] Requirements - rev1 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:00:36 -0000 I suspect it comes down to the definition you are using of responsible. May= be you would like to elaborate on what that term means, rather than what ha= ppens when it is applied as a condition (which is all we get from RFC 3261)= . 3GPP does not actually specify how domain names are used in IMS. GSMA has s= ome work, but the rest is left to deployment. =20 In general we have considered it under the same assumptions as domain names= are handled in email - I can ask someone else to host my domain name, etc. regards Keith > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Wednesday, January 27, 2010 3:47 AM > To: DRAGE, Keith (Keith) > Cc: Elwell, John; martini@ietf.org > Subject: Re: [martini] Requirements - rev1 >=20 >=20 > On Jan 26, 2010, at 9:47 AM, DRAGE, Keith (Keith) wrote: >=20 > > I've just read my way through this entire thread again. > >=20 > > So going back to the start, what IMS does is mechanism 1), not 3). >=20 > I'm not really sure it makes much difference for deciding=20 > what to do here, but when I look at 3GPP R5, it looks to me=20 > very much that the SSP was responsible for the domain and not=20 > the terminal. Part of the point of IMS was the service=20 > provider, not the terminal, being able to create and control=20 > services. So I come to a very different conclusion about if=20 > it is 1 or 3. Now I'd be the first to say than Keith=20 > understands 3GPP better than I ever will but I'm just not=20 > understanding how you come to the conclusion that the service=20 > provider was not responsible, in the 3261 sense of=20 > responsible, for the AOR.=20 >=20 >=20 > >=20 > > If does this on the basis that we are trying to simulate as=20 > much as possible what a proxy doing an ordinary DNS look up=20 > would do. However it includes the extra Route header value=20 > because it needs to get through the rest of the IMS proxies=20 > to the gateway PBX. > >=20 > > As such any issues probably exist in the straight network=20 > peering solution as well. I would make the following points: > >=20 > > 1) Dean quite rightly stated that the enterprise operator=20 > is devolving some responsibility to the SSP. In TISPAN/3GPP,=20 > the view is essentially that the SSP is providing some form=20 > of virtual transit PBX, which the SSP rents to the enterprise=20 > provider.So the devolving of DNS responsibility is on the=20 > basis of that. > >=20 > > 2) The number routing problem is no different to that that=20 > exists between two SSPs. If you are a user with 123 @=20 > ssp_example1 and I make a call to 123 @ ssp_example2, what=20 > does ssp_example2 do with this call. Either it ignores the=20 > domain name and processes it anyway - something that is not=20 > allowed by IETF but many operators do anyway, or it rejects=20 > the call. I don't expect anything different to happen in the=20 > business trunking. Thus the correct address for users on the=20 > PBX is number@pbx.com, not number@ssp.com. How the SSP=20 > handlesnumber@ssp.com is not going to alter based on an IETF=20 > edict, but it will be the SSP breaking the rules. > >=20 > > regards > >=20 > > Keith >=20 > Cullen >=20 > = From dwsauder@dsauder.com Wed Jan 27 17:22:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81F613A68BE for ; Wed, 27 Jan 2010 17:22: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 ZBLjXrvypX9F for ; Wed, 27 Jan 2010 17:22:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 13B2E3A6879 for ; Wed, 27 Jan 2010 17:22:41 -0800 (PST) Received: from [192.168.1.149] (dsl092-171-201.wdc2.dsl.speakeasy.net [66.92.171.201]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LnPWQ-1OHdSu1NLq-00hVa0; Wed, 27 Jan 2010 20:22:54 -0500 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Doug Sauder In-Reply-To: Date: Wed, 27 Jan 2010 20:22:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) X-Provags-ID: V01U2FsdGVkX187rAZjIshdE1k/k/X66//DNH+7KYu2P0PH2au 0b24Pe3VSq4IvUOl8o7KyoMRi5Y9M+m+SNGKyB+cdD4wygsrHf xO5L93It7dMP/K/wrrn+i2x3yIP7hQN Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 01:22:42 -0000 Hi, all! I have been wanting to jump into the discussion here as a contributor = who has experience with the SSP-side software. I have been at BroadSoft = for long time, and I have extensive knowledge of BroadSoft's SIP = trunking technology. I point this out, because I'm not using my = BroadSoft email address, which would have made my affiliation more = obvious. Sorry that I can't speak from the perspective of an actual SSP -- only = from that of a technology provider. As a B2BUA at the SSP, we make a clear distinction between the network = side interface (facing a PSTN gateway, for example) and the access side = interface (facing a PBX, most likely behind an SBC or two). On the = network side, outside of an IMS deployment, we deal almost exclusively = with telephone numbers. =46rom the PSTN, those would be E.164 numbers. = On the access side, there are a number of options that can be configured = ("contact routing" being one of them). A key point is that every PBX = subscriber is provisioned by the SSP, and it is not necessary for a = REGISTER to tie AORs and contact URIs explicitly. Of course, the SSP = wants to provide not only PSTN connectivity to their customers, but also = value-added services, such as services for teleworkers (as was brought = up earlier on the Martini list). Thus, the explicit provisioning of = subscribers by the SSP is pretty standard practice. This provides the = answer to John's question below, about how the "proxy" knows which PBX = to route to: it is explicitly provisioned by the SSP. On some of the points that were raised in the last few days, my two = cents... 1. I definitely agree that narrowing the problem to focus on E.164 = numbers yields a lot of bang for the buck. I don't see a problem with = non-E.164 numbers, though, as the phone context provides a namespace and = doesn't imply anything about routing. 2. The "contact routing" option makes a lot of sense to me, in that it = avoids a lot of the problems that have been discussed. 3. I see no need to use a P-Associated-URI header field or similar = header field in a REGISTER response. I don't see how it is that useful = for troubleshooting, as the administrative staff of the PBX and has some = self-service administrative privileges at the SSP. -- Doug On Jan 27, 2010, at 11:04 , Dean Willis wrote: >=20 > On Jan 27, 2010, at 4:19 AM, Elwell, John wrote: >=20 >>=20 >>=20 >> The motivation for restricting to AORs based on E.164 numbers was = basically that E.164 numbers are not tied to domains, and the practice = of changing the domain part of a SIP URI without changing the user part = is more palatable. However, Hadriel has recently argued (and found = support from some people) that this is outside the scope of MARTINI. = Either my request starts off being targeted at sip:user@pbx.com and DNS = takes it first to the SP (the SP having delegated responsibility for = pbx.com), which then uses MARTINI procedures to route to pbx.com. Or my = request starts off being targeted at sip:user@sp.com, and on arrival at = the SP there is some manipulation of the Request-URI so that it becomes = sip:user@pbx.com. It is this manipulation that seems to be acceptable = for E.164-based AORs but not for others. But, as Hadriel points out, = MARTINI does not need to cover the issue of how the request reaches the = SP, only the fact that the SP has a request targeted at pbx.com and = needs a means of routing it there. So in my opinion, motivation for = limiting to E.164-based AORs is rather weak. Nevertheless, if we can = indeed come up with something simpler by having this limitation, that = would be fine if we have a suitable story for related issues (private = number, call transfer, etc.). >=20 > Richard sees to be saying that the use case "A call shows up at SSP = with a URI of @pbx.com" is out-of-scope for his use case (except = POSSIBLY for the result of call transfer). >=20 > The fundamental SIPConnect use cases, as I understand them, are: >=20 > 1) A call shows up at an SSP's gateway for some phone number, say = "+15125551212". The gateway sends the resulting INVITE to SSP's proxy. = How does this proxy know which PBX to send the call to? >=20 > 2) An INVITE shows up at an SSP's SBC for some phone number, say = "+15125551212" that is scoped to the SSP's domain by being "@ssp.com"". = The SBC forwards the INVITE to SSP's proxy. How does this proxy know = which PBX to send the call to? >=20 >=20 > Where, in the SIPConnect model, does "@pbx.com" come into play? We've = suggested that it might do so, if PBX mints and uses a GRUU, and that = GRUU is scoped into the domain of "pbx.com". But this is silly; the = whole reason for using MARTINI is that "@pbx.com" is either useless, or = points to the SSP. So really, what we need to do is have the SSP mint a = GRUU, scoped to "@ssp.com", which is then used by PBX in call-transfer = scenarios. >=20 > Is there any other reason to have "@pbx.com" in the current problem = scope? >=20 >=20 > Yes, figuring out how to do dynamically-associated relay services for = domain-scoped messages is important. But it's a different and completely = separable problem (although once solved, we might find that the solution = backward-applies to the telephone problem). However, I firmly believe = that solving it requires solving some of the fundamental design problems = in SIP, such as the fact that our model for registering a multi-hop = route is pretty hokey (combining RFC 3261's REGISTER, Service-Route, = Path, Outbound, connect-Reuse, and a mess of unimplemented public keys = stuff). I think it's gonna be a while before we solve the general = dynamically-associated relay services for domain-scoped messages = problem. >=20 >=20 > -- > Dean > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From bruno.chatras@orange-ftgroup.com Thu Jan 28 02:05:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745F53A6845 for ; Thu, 28 Jan 2010 02:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 t-cUa-phwKnh for ; Thu, 28 Jan 2010 02:05:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 39CD13A6814 for ; Thu, 28 Jan 2010 02:05:25 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 9782B1B85B7; Thu, 28 Jan 2010 11:05:41 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6A6C3158078; Thu, 28 Jan 2010 11:05:41 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 11:05:41 +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, 28 Jan 2010 11:05:40 +0100 Message-ID: <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqfGG4LHcBDOAo4QAmgvsHFtgT3jwA13Ucg References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> From: To: , X-OriginalArrivalTime: 28 Jan 2010 10:05:41.0011 (UTC) FILETIME=[72837630:01CAA001] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.28.84224 Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 10:05:26 -0000 Looking to this proposal, another question comes to my mind. There is some= thing that I don't understand from an Industry viewpoint. - 3GPP/ETSI have defined a solution that applies to all types of identities= (E.164 numbers, private numbers and email-style URI). For various reasons = this solution is not deemed suitable by the MARTINI community.=20 - The alternative proposal seems to be to first create a near-time solution= that works for E.164 numbers only and address the other cases at a later s= tage, possibly through a totally different solution.=20 Considering that the three types of identities will have to be supported at= some point in time anyway, I'm wondering what could be the motivation of t= he Industry to adopt the E.164-only solution as a near-term solution rather= than the 3GPP/ETSI solution? This can only happen if the E-164 solution ha= s very strong benefits and the 3GPP/ETSI solution has major flaws that prev= ents its implementation. /BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Dean Willis > Envoy=E9 : mercredi 27 janvier 2010 07:16 > =C0 : martini@ietf.org > Objet : [martini] Proposed work split: tackle=20 > telephone-number registrationfirst >=20 >=20 > We seem to have an urgent need for a near-term solution for=20 > dealing with the subset of the MARTINI problem that, loosely=20 > defined, covers the "telephone number" problem. >=20 > The typical scenario here is SIP trunking, wherein a SIP=20 > Service Provider (SSP) provides an ISDN-PRI like service over=20 > IP to a=20=20 > customer's PBX (or PBXes). In this model, the SSP maps a=20 > whole bunch=20=20=20 > of phone numbers to the PBXes. This mapping is somewhat=20 > dynamic, because the PBXes usually have DHCP addresses, and=20 > don't have DNS entries that point A records at the PBX in any=20 > sort of particularly useful way (maybe something like=20 > dhcp-10-1-2-3-example.com). >=20 > So what we need is a way for a PBX, when it reboots (or perhaps > periodically) to say to the SSP "Here I Am; You may now send=20 > any calls for my assigned phone numbers to my current Contact." >=20 > This is indeed a "registration" problem, but it isn't=20 > necessarily a "domain registration problem". The only reason=20 > domains get mixed into this scenario at all is that we=20 > sometimes encode telephone numbers as the user parts of SIP=20 > URIs, and those SIP URIs have a domain part attached to them. >=20 > More interestingly, this problem is a tiny subset of the=20 > whole MARTINI dynamic binding problem, and it potentially can=20 > be solved much more simply than the general problem. >=20 > On today's Interim II call, Richard, Adam and I raised the=20 > idea of dividing our problem space, and taking on a near-term=20 > milestone for delivering a MARTINI solution for registering=20 > contacts to a proxy, where that proxy maps one or more=20 > telephone numbers to the contact. >=20 > We certainly intend to go on and tackle the more general=20 > domain- registration problem, but I (and I believe Adam and=20 > Richard) believe that we get a lot out of tackling the=20 > telephone-number subset first. >=20 > In particular, we believe that this approach solves many of=20 > the domain "responsibility" questions, simplifies the TLS=20 > keying/certification model immensely, eliminates the=20 > cognitive overload of using REGISTER to bind a "domain" to a=20 > Contact, "route authentication", and a good many other open=20 > issues that plague our current drafts. >=20 >=20 > Open questions relating to this approach include: >=20 > 1) Do we deal only with E.164 numbers, or do we need to deal=20 > with private-number "phone contexts"? >=20 > 2) D owe need to explicitly encode the telephone numbers=20 > being registered in the REGISTER request (either directly or=20 > through some sort of regexp), or is it adequate to rely on=20 > provisioning of the SSP and PBX (and any UAs) to statically=20 > bind the numbers to the PBX identity, and then dynamically=20 > only register the PBX identity to the PBX contact? >=20 > 3) Can we "register" with a tel: URI as the "To" value? (this=20 > seems to require extending RFC 3261)? Note that "tel:" can=20 > express both E.164 numbers and private phone-contexts in one format. >=20 > 4) What happens with GRUUs? >=20 > I believe all of these issues are quite tractable, if we=20 > accept the fundamental idea of splitting the phone-number=20 > problem off from the more general domain-registration, and=20 > recognize the possibility that the solutions to the two=20 > problem may reasonably be quite different from each other. >=20 > So, what do you people think? Is it worth trying to drink the=20 > MARTINI elephant one sip at a time, or are we going to treat=20 > the whole thing like a tequila shot and just slam it down? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From HKaplan@acmepacket.com Thu Jan 28 08:58:23 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05CD3A6A76 for ; Thu, 28 Jan 2010 08:58:23 -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_24=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 9oUojJN7d-hX for ; Thu, 28 Jan 2010 08:58:23 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C36893A6840 for ; Thu, 28 Jan 2010 08:58:22 -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, 28 Jan 2010 11:58:40 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jan 2010 11:58:40 -0500 From: Hadriel Kaplan To: Doug Sauder , Dean Willis Date: Thu, 28 Jan 2010 11:58:41 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registration first Thread-Index: AcqfuG6VlLzgBJ6dSb2TUR9KPgH2rQAgSgdQ Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 16:58:23 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Doug Sauder > Sent: Wednesday, January 27, 2010 8:23 PM > To: Dean Willis > A key point is that every PBX > subscriber is provisioned by the SSP, and it is not necessary for a > REGISTER to tie AORs and contact URIs explicitly. Of course, the SSP > wants to provide not only PSTN connectivity to their customers, but also > value-added services, such as services for teleworkers (as was brought up > earlier on the Martini list). Thus, the explicit provisioning of > subscribers by the SSP is pretty standard practice. This provides the > answer to John's question below, about how the "proxy" knows which PBX t > o route to: it is explicitly provisioned by the SSP. Yes but we're trying to avoid that - obviously the phone numbers and shared= secret password stuff has to be provisioned in the SSP, but we're trying t= o avoid provisioning the IP:port and transport of the PBX and which specifi= c proxies/SBCs to traverse to reach it (so that, for example, the proxies/S= BCs can dynamically change easily). This wouldn't be for large company IP-= PBX's really - someone like WalMart or GE or whatever would get white-glove= treatment by their SSP's anyway... this is more for the SMB market. > 3. I see no need to use a P-Associated-URI header field or similar header > field in a REGISTER response. I don't see how it is that useful for > troubleshooting, as the administrative staff of the PBX and has some self= - > service administrative privileges at the SSP. It was for two reasons: (1) the troubleshooting aspect, where an SMB doesn'= t have an "administrative staff" for PBX's and even for the SSP it would be= nice to get a log/alarm of mismatched numbers a priori, and (2) for the P-= CSCF/edge-proxy/SBC's which do P-Asserted-ID assertion or call blocking of = unknown/unregistered sources. But I don't know if it's worth it in the end= , if folks get hung up over it here. -hadriel From HKaplan@acmepacket.com Thu Jan 28 09:24:20 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00EF83A67EC for ; Thu, 28 Jan 2010 09:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 T94XNe6+wnYv for ; Thu, 28 Jan 2010 09:24:19 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 088403A67E4 for ; Thu, 28 Jan 2010 09:24:19 -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, 28 Jan 2010 12:24:37 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jan 2010 12:24:36 -0500 From: Hadriel Kaplan To: "bruno.chatras@orange-ftgroup.com" , "dean.willis@softarmor.com" , "martini@ietf.org" Date: Thu, 28 Jan 2010 12:24:34 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqfGG4LHcBDOAo4QAmgvsHFtgT3jwA13UcgABLRTQA= Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> 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: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:24:20 -0000 Hi Bruno, comments inline... > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of bruno.chatras@orange-ftgroup.com > Sent: Thursday, January 28, 2010 5:06 AM >=20 > Looking to this proposal, another question comes to my mind. There is > something that I don't understand from an Industry viewpoint. >=20 > - 3GPP/ETSI have defined a solution that applies to all types of > identities (E.164 numbers, private numbers and email-style URI). For > various reasons this solution is not deemed suitable by the MARTINI > community. Martini was instigated from work we were doing in SIP-Forum, and in the SIP= -Forum at one point we were nearly identical to the 3gpp/etsi mechanism, bu= t technical objections and issues were raised, which drove us to go to the = IETF. The 50,000ft view of the issues were that the 3gpp/etsi model "works= " as long as everyone's on the same page - that they all happen to be provi= sioned to implement the exact same procedures from the same version of the = specs. They all have to know that the "normal" procedures of 3261 are not = being followed, and they have to know which procedures are being followed, = without any on-the-wire indication that or what they are. For example, the= y have to know that the request-URI is or is not going to be the registered= contact (it can be either way, just based on a provisioned field).=20 That's all fine on the SSP-side, because presumably they control all their = own equipment. But on the Enterprise side it's harder. In particular, whi= le we've seen plenty of IMS equipment support it, we've seen a very small p= ercentage of PBX's do so, relatively. Obviously the same will/can be said of any Martini or SIP-Forum work - all = the devices will have to do Martini (whatever it is) for it to work. There= will be an on-the-wire indication of it, so at least one can know what the= other device does or needs, so that's better, but at the end of the day as= you said the question is whether the industry will adopt it. In the best = case scenario 3GPP, ETSI, SIP-Forum, and CableLabs will all adopt the Marti= ni work - possibly as an alternative, or maybe even as the new way. For ex= ample the draft-shaken model is very close/similar to the current 3gpp mode= l. =20 -hadriel From HKaplan@acmepacket.com Thu Jan 28 09:28:58 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58253A6941 for ; Thu, 28 Jan 2010 09:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 KjFok0lqfQtG for ; Thu, 28 Jan 2010 09:28:57 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BBB883A67EC for ; Thu, 28 Jan 2010 09:28:57 -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, 28 Jan 2010 12:29:15 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jan 2010 12:29:15 -0500 From: Hadriel Kaplan To: Dean Willis , "martini@ietf.org" Date: Thu, 28 Jan 2010 12:29:16 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registration first Thread-Index: AcqfGFaAJbb0KELeTQ+JJzhIW48tcABJnvEQ Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.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: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:28:59 -0000 This is a great summary of the issues. I don't actually think focusing on = E.164 numbers will make this any easier, and my guess is the solution we co= me up with for that will work for private numbers and email-style too, but = just to move forward I'm game to focus on just E.164. BTW, the concerns raised on the call/list kept using the phrase "domain reg= istration" as an issue - were you referring to the draft-stirred model? Is= the draft-shaken model more palatable then? I was all for dismissing the = draft-stirred one at the first Virtual meeting, and still am. :) -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Dean Willis > Sent: Wednesday, January 27, 2010 1:16 AM > To: martini@ietf.org > Subject: [martini] Proposed work split: tackle telephone-number > registration first >=20 >=20 > We seem to have an urgent need for a near-term solution for dealing > with the subset of the MARTINI problem that, loosely defined, covers > the "telephone number" problem. >=20 > The typical scenario here is SIP trunking, wherein a SIP Service > Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's PBX (or PBXes). In this model, the SSP maps a whole bunch > of phone numbers to the PBXes. This mapping is somewhat dynamic, > because the PBXes usually have DHCP addresses, and don't have DNS > entries that point A records at the PBX in any sort of particularly > useful way (maybe something like dhcp-10-1-2-3-example.com). >=20 > So what we need is a way for a PBX, when it reboots (or perhaps > periodically) to say to the SSP "Here I Am; You may now send any calls > for my assigned phone numbers to my current Contact." >=20 > This is indeed a "registration" problem, but it isn't necessarily a > "domain registration problem". The only reason domains get mixed into > this scenario at all is that we sometimes encode telephone numbers as > the user parts of SIP URIs, and those SIP URIs have a domain part > attached to them. >=20 > More interestingly, this problem is a tiny subset of the whole MARTINI > dynamic binding problem, and it potentially can be solved much more > simply than the general problem. >=20 > On today's Interim II call, Richard, Adam and I raised the idea of > dividing our problem space, and taking on a near-term milestone for > delivering a MARTINI solution for registering contacts to a proxy, > where that proxy maps one or more telephone numbers to the contact. >=20 > We certainly intend to go on and tackle the more general domain- > registration problem, but I (and I believe Adam and Richard) believe > that we get a lot out of tackling the telephone-number subset first. >=20 > In particular, we believe that this approach solves many of the domain > "responsibility" questions, simplifies the TLS keying/certification > model immensely, eliminates the cognitive overload of using REGISTER > to bind a "domain" to a Contact, "route authentication", and a good > many other open issues that plague our current drafts. >=20 >=20 > Open questions relating to this approach include: >=20 > 1) Do we deal only with E.164 numbers, or do we need to deal with > private-number "phone contexts"? >=20 > 2) D owe need to explicitly encode the telephone numbers being > registered in the REGISTER request (either directly or through some > sort of regexp), or is it adequate to rely on provisioning of the SSP > and PBX (and any UAs) to statically bind the numbers to the PBX > identity, and then dynamically only register the PBX identity to the > PBX contact? >=20 > 3) Can we "register" with a tel: URI as the "To" value? (this seems to > require extending RFC 3261)? Note that "tel:" can express both E.164 > numbers and private phone-contexts in one format. >=20 > 4) What happens with GRUUs? >=20 > I believe all of these issues are quite tractable, if we accept the > fundamental idea of splitting the phone-number problem off from the > more general domain-registration, and recognize the possibility that > the solutions to the two problem may reasonably be quite different > from each other. >=20 > So, what do you people think? Is it worth trying to drink the MARTINI > elephant one sip at a time, or are we going to treat the whole thing > like a tequila shot and just slam it down? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Thu Jan 28 09:35:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BBF3A6AAD for ; Thu, 28 Jan 2010 09:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdeWy6Yduk6g for ; Thu, 28 Jan 2010 09:35:42 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4DDDE3A67BD for ; Thu, 28 Jan 2010 09:35:42 -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, 28 Jan 2010 12:36:00 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 28 Jan 2010 12:36:00 -0500 From: Hadriel Kaplan To: Dean Willis , "martini@ietf.org" Date: Thu, 28 Jan 2010 12:36:01 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registration first Thread-Index: AcqfGFaAJbb0KELeTQ+JJzhIW48tcABJ0lBA Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.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: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:35:47 -0000 BTW, I find it funny how folks are all concerned about Domain ownership and= the security properties of allowing a device to Register a Domain name for= SIP request routing to, but when it comes to whole blocks of E.164 numbers= we're all fine and dandy with a device claiming ownership of that. This d= espite the fact that E.164's are the 99% use case for SIP at large. Like i= t's scary that a device could claim to be responsible for SIP of cisco.com,= but it's ok if it claims to be all of Cisco's E.164 numbers. :) -hadriel > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Dean Willis > Sent: Wednesday, January 27, 2010 1:16 AM > To: martini@ietf.org > Subject: [martini] Proposed work split: tackle telephone-number > registration first >=20 >=20 > We seem to have an urgent need for a near-term solution for dealing > with the subset of the MARTINI problem that, loosely defined, covers > the "telephone number" problem. >=20 > The typical scenario here is SIP trunking, wherein a SIP Service > Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's PBX (or PBXes). In this model, the SSP maps a whole bunch > of phone numbers to the PBXes. This mapping is somewhat dynamic, > because the PBXes usually have DHCP addresses, and don't have DNS > entries that point A records at the PBX in any sort of particularly > useful way (maybe something like dhcp-10-1-2-3-example.com). >=20 > So what we need is a way for a PBX, when it reboots (or perhaps > periodically) to say to the SSP "Here I Am; You may now send any calls > for my assigned phone numbers to my current Contact." >=20 > This is indeed a "registration" problem, but it isn't necessarily a > "domain registration problem". The only reason domains get mixed into > this scenario at all is that we sometimes encode telephone numbers as > the user parts of SIP URIs, and those SIP URIs have a domain part > attached to them. >=20 > More interestingly, this problem is a tiny subset of the whole MARTINI > dynamic binding problem, and it potentially can be solved much more > simply than the general problem. >=20 > On today's Interim II call, Richard, Adam and I raised the idea of > dividing our problem space, and taking on a near-term milestone for > delivering a MARTINI solution for registering contacts to a proxy, > where that proxy maps one or more telephone numbers to the contact. >=20 > We certainly intend to go on and tackle the more general domain- > registration problem, but I (and I believe Adam and Richard) believe > that we get a lot out of tackling the telephone-number subset first. >=20 > In particular, we believe that this approach solves many of the domain > "responsibility" questions, simplifies the TLS keying/certification > model immensely, eliminates the cognitive overload of using REGISTER > to bind a "domain" to a Contact, "route authentication", and a good > many other open issues that plague our current drafts. >=20 >=20 > Open questions relating to this approach include: >=20 > 1) Do we deal only with E.164 numbers, or do we need to deal with > private-number "phone contexts"? >=20 > 2) D owe need to explicitly encode the telephone numbers being > registered in the REGISTER request (either directly or through some > sort of regexp), or is it adequate to rely on provisioning of the SSP > and PBX (and any UAs) to statically bind the numbers to the PBX > identity, and then dynamically only register the PBX identity to the > PBX contact? >=20 > 3) Can we "register" with a tel: URI as the "To" value? (this seems to > require extending RFC 3261)? Note that "tel:" can express both E.164 > numbers and private phone-contexts in one format. >=20 > 4) What happens with GRUUs? >=20 > I believe all of these issues are quite tractable, if we accept the > fundamental idea of splitting the phone-number problem off from the > more general domain-registration, and recognize the possibility that > the solutions to the two problem may reasonably be quite different > from each other. >=20 > So, what do you people think? Is it worth trying to drink the MARTINI > elephant one sip at a time, or are we going to treat the whole thing > like a tequila shot and just slam it down? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Thu Jan 28 09:50:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611223A6819 for ; Thu, 28 Jan 2010 09:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.509 X-Spam-Level: X-Spam-Status: No, score=-10.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpwH3Lnib5Aq for ; Thu, 28 Jan 2010 09:50:42 -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 153683A67C1 for ; Thu, 28 Jan 2010 09:50:42 -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: ApoEAOZcYUutJV2b/2dsb2JhbADCdIlnAY1Ngi8NggAEjhs X-IronPort-AV: E=Sophos;i="4.49,361,1262563200"; d="scan'208";a="82731764" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 28 Jan 2010 17:51:00 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o0SHoxKm026639; Thu, 28 Jan 2010 17:50:59 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 11:50:59 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 11:50:59 -0600 Message-ID: <4B61CE78.20605@cisco.com> Date: Thu, 28 Jan 2010 12:50:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hadriel Kaplan References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2010 17:50:59.0622 (UTC) FILETIME=[734D6C60:01CAA042] Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 17:50:46 -0000 Hadriel Kaplan wrote: > BTW, I find it funny how folks are all concerned about Domain ownership and the security properties of allowing a device to Register a Domain name for SIP request routing to, but when it comes to whole blocks of E.164 numbers we're all fine and dandy with a device claiming ownership of that. This despite the fact that E.164's are the 99% use case for SIP at large. Like it's scary that a device could claim to be responsible for SIP of cisco.com, but it's ok if it claims to be all of Cisco's E.164 numbers. :) There is, I think, a big difference. Claiming ownership doesn't mean that you will be granted ownership. In the case of phone numbers, I have been assuming that the SSP knows which numbers it has control over, and which have been contractually agreed to be delegated to the PBX. But the SSP isn't in charge of domain names. If I register with the SSP and say I want to receive requests for whitehouse.gov, how can it determine if that is proper or not? It could if *it* registered the domain names on behalf of the customers. But if the customer says to the SSP "I already own this domain and will arrange for requests to it to be routed to you, so when you get them please forward them on to my pbx", how is the SSP to decide if that is ok or not? Thanks, Paul > -hadriel > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Dean Willis >> Sent: Wednesday, January 27, 2010 1:16 AM >> To: martini@ietf.org >> Subject: [martini] Proposed work split: tackle telephone-number >> registration first >> >> >> We seem to have an urgent need for a near-term solution for dealing >> with the subset of the MARTINI problem that, loosely defined, covers >> the "telephone number" problem. >> >> The typical scenario here is SIP trunking, wherein a SIP Service >> Provider (SSP) provides an ISDN-PRI like service over IP to a >> customer's PBX (or PBXes). In this model, the SSP maps a whole bunch >> of phone numbers to the PBXes. This mapping is somewhat dynamic, >> because the PBXes usually have DHCP addresses, and don't have DNS >> entries that point A records at the PBX in any sort of particularly >> useful way (maybe something like dhcp-10-1-2-3-example.com). >> >> So what we need is a way for a PBX, when it reboots (or perhaps >> periodically) to say to the SSP "Here I Am; You may now send any calls >> for my assigned phone numbers to my current Contact." >> >> This is indeed a "registration" problem, but it isn't necessarily a >> "domain registration problem". The only reason domains get mixed into >> this scenario at all is that we sometimes encode telephone numbers as >> the user parts of SIP URIs, and those SIP URIs have a domain part >> attached to them. >> >> More interestingly, this problem is a tiny subset of the whole MARTINI >> dynamic binding problem, and it potentially can be solved much more >> simply than the general problem. >> >> On today's Interim II call, Richard, Adam and I raised the idea of >> dividing our problem space, and taking on a near-term milestone for >> delivering a MARTINI solution for registering contacts to a proxy, >> where that proxy maps one or more telephone numbers to the contact. >> >> We certainly intend to go on and tackle the more general domain- >> registration problem, but I (and I believe Adam and Richard) believe >> that we get a lot out of tackling the telephone-number subset first. >> >> In particular, we believe that this approach solves many of the domain >> "responsibility" questions, simplifies the TLS keying/certification >> model immensely, eliminates the cognitive overload of using REGISTER >> to bind a "domain" to a Contact, "route authentication", and a good >> many other open issues that plague our current drafts. >> >> >> Open questions relating to this approach include: >> >> 1) Do we deal only with E.164 numbers, or do we need to deal with >> private-number "phone contexts"? >> >> 2) D owe need to explicitly encode the telephone numbers being >> registered in the REGISTER request (either directly or through some >> sort of regexp), or is it adequate to rely on provisioning of the SSP >> and PBX (and any UAs) to statically bind the numbers to the PBX >> identity, and then dynamically only register the PBX identity to the >> PBX contact? >> >> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >> require extending RFC 3261)? Note that "tel:" can express both E.164 >> numbers and private phone-contexts in one format. >> >> 4) What happens with GRUUs? >> >> I believe all of these issues are quite tractable, if we accept the >> fundamental idea of splitting the phone-number problem off from the >> more general domain-registration, and recognize the possibility that >> the solutions to the two problem may reasonably be quite different >> from each other. >> >> So, what do you people think? Is it worth trying to drink the MARTINI >> elephant one sip at a time, or are we going to treat the whole thing >> like a tequila shot and just slam it down? >> >> -- >> Dean >> >> >> >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From eburger@standardstrack.com Thu Jan 28 10:17:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907343A6862 for ; Thu, 28 Jan 2010 10:17: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=[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 I90wYtOJFWjs for ; Thu, 28 Jan 2010 10:17:46 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 18C863A6803 for ; Thu, 28 Jan 2010 10:17:46 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.143]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NaYwL-0001nw-0Q; Thu, 28 Jan 2010 10:18:01 -0800 Message-Id: <6D4617A8-66CC-422C-BE43-8C3F3C61D62C@standardstrack.com> From: Eric Burger To: Hadriel Kaplan In-Reply-To: <4B61CE78.20605@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: Thu, 28 Jan 2010 13:18:01 -0500 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <4B61CE78.20605@cisco.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: Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:17:47 -0000 And, I know of providers out there that can vouch for the voracity of TN ownership :-) On Jan 28, 2010, at 12:50 PM, Paul Kyzivat wrote: > > > Hadriel Kaplan wrote: >> BTW, I find it funny how folks are all concerned about Domain >> ownership and the security properties of allowing a device to >> Register a Domain name for SIP request routing to, but when it >> comes to whole blocks of E.164 numbers we're all fine and dandy >> with a device claiming ownership of that. This despite the fact >> that E.164's are the 99% use case for SIP at large. Like it's >> scary that a device could claim to be responsible for SIP of >> cisco.com, but it's ok if it claims to be all of Cisco's E.164 >> numbers. :) > > There is, I think, a big difference. > > Claiming ownership doesn't mean that you will be granted ownership. > In the case of phone numbers, I have been assuming that the SSP > knows which numbers it has control over, and which have been > contractually agreed to be delegated to the PBX. > > But the SSP isn't in charge of domain names. > If I register with the SSP and say I want to receive requests for > whitehouse.gov, how can it determine if that is proper or not? > > It could if *it* registered the domain names on behalf of the > customers. But if the customer says to the SSP "I already own this > domain and will arrange for requests to it to be routed to you, so > when you get them please forward them on to my pbx", how is the SSP > to decide if that is ok or not? > > Thanks, > Paul > >> -hadriel >>> -----Original Message----- >>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] >>> On Behalf >>> Of Dean Willis >>> Sent: Wednesday, January 27, 2010 1:16 AM >>> To: martini@ietf.org >>> Subject: [martini] Proposed work split: tackle telephone-number >>> registration first >>> >>> >>> We seem to have an urgent need for a near-term solution for dealing >>> with the subset of the MARTINI problem that, loosely defined, covers >>> the "telephone number" problem. >>> >>> The typical scenario here is SIP trunking, wherein a SIP Service >>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>> customer's PBX (or PBXes). In this model, the SSP maps a whole bunch >>> of phone numbers to the PBXes. This mapping is somewhat dynamic, >>> because the PBXes usually have DHCP addresses, and don't have DNS >>> entries that point A records at the PBX in any sort of particularly >>> useful way (maybe something like dhcp-10-1-2-3-example.com). >>> >>> So what we need is a way for a PBX, when it reboots (or perhaps >>> periodically) to say to the SSP "Here I Am; You may now send any >>> calls >>> for my assigned phone numbers to my current Contact." >>> >>> This is indeed a "registration" problem, but it isn't necessarily a >>> "domain registration problem". The only reason domains get mixed >>> into >>> this scenario at all is that we sometimes encode telephone numbers >>> as >>> the user parts of SIP URIs, and those SIP URIs have a domain part >>> attached to them. >>> >>> More interestingly, this problem is a tiny subset of the whole >>> MARTINI >>> dynamic binding problem, and it potentially can be solved much more >>> simply than the general problem. >>> >>> On today's Interim II call, Richard, Adam and I raised the idea of >>> dividing our problem space, and taking on a near-term milestone for >>> delivering a MARTINI solution for registering contacts to a proxy, >>> where that proxy maps one or more telephone numbers to the contact. >>> >>> We certainly intend to go on and tackle the more general domain- >>> registration problem, but I (and I believe Adam and Richard) believe >>> that we get a lot out of tackling the telephone-number subset first. >>> >>> In particular, we believe that this approach solves many of the >>> domain >>> "responsibility" questions, simplifies the TLS keying/certification >>> model immensely, eliminates the cognitive overload of using REGISTER >>> to bind a "domain" to a Contact, "route authentication", and a good >>> many other open issues that plague our current drafts. >>> >>> >>> Open questions relating to this approach include: >>> >>> 1) Do we deal only with E.164 numbers, or do we need to deal with >>> private-number "phone contexts"? >>> >>> 2) D owe need to explicitly encode the telephone numbers being >>> registered in the REGISTER request (either directly or through some >>> sort of regexp), or is it adequate to rely on provisioning of the >>> SSP >>> and PBX (and any UAs) to statically bind the numbers to the PBX >>> identity, and then dynamically only register the PBX identity to the >>> PBX contact? >>> >>> 3) Can we "register" with a tel: URI as the "To" value? (this >>> seems to >>> require extending RFC 3261)? Note that "tel:" can express both E.164 >>> numbers and private phone-contexts in one format. >>> >>> 4) What happens with GRUUs? >>> >>> I believe all of these issues are quite tractable, if we accept the >>> fundamental idea of splitting the phone-number problem off from the >>> more general domain-registration, and recognize the possibility that >>> the solutions to the two problem may reasonably be quite different >>> from each other. >>> >>> So, what do you people think? Is it worth trying to drink the >>> MARTINI >>> elephant one sip at a time, or are we going to treat the whole thing >>> like a tequila shot and just slam it down? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From eburger@standardstrack.com Thu Jan 28 10:19:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4CC3A6803 for ; Thu, 28 Jan 2010 10:19:31 -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 k8YrPjnAX0Nh for ; Thu, 28 Jan 2010 10:19:30 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id B05543A67D4 for ; Thu, 28 Jan 2010 10:19:30 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.143]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NaYy0-0002IX-NC; Thu, 28 Jan 2010 10:19:44 -0800 Message-Id: <994FE530-28D0-4686-AF35-71AD5A0E1872@standardstrack.com> From: Eric Burger To: bruno.chatras@orange-ftgroup.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 13:19:45 -0500 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> 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: Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:19:31 -0000 More to the point, we have absolutely no intention of doing the ETSI/ 3GPP thing of creating something that looks almost compatible with SIP, but really is not. The mechanism here, while it needs MARTINI- aware devices to be aware of MARTINI (no sequitur of the day), non- MARTINI-aware devices will still be able to communicate with MARTINI- aware devices, and vice-versa. The same is NOT true of the ETSI/3GPP approach. On Jan 28, 2010, at 12:24 PM, Hadriel Kaplan wrote: > Hi Bruno, comments inline... > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf >> Of bruno.chatras@orange-ftgroup.com >> Sent: Thursday, January 28, 2010 5:06 AM >> >> Looking to this proposal, another question comes to my mind. There >> is >> something that I don't understand from an Industry viewpoint. >> >> - 3GPP/ETSI have defined a solution that applies to all types of >> identities (E.164 numbers, private numbers and email-style URI). For >> various reasons this solution is not deemed suitable by the MARTINI >> community. > > Martini was instigated from work we were doing in SIP-Forum, and in > the SIP-Forum at one point we were nearly identical to the 3gpp/etsi > mechanism, but technical objections and issues were raised, which > drove us to go to the IETF. The 50,000ft view of the issues were > that the 3gpp/etsi model "works" as long as everyone's on the same > page - that they all happen to be provisioned to implement the exact > same procedures from the same version of the specs. They all have > to know that the "normal" procedures of 3261 are not being followed, > and they have to know which procedures are being followed, without > any on-the-wire indication that or what they are. For example, they > have to know that the request-URI is or is not going to be the > registered contact (it can be either way, just based on a > provisioned field). > > That's all fine on the SSP-side, because presumably they control all > their own equipment. But on the Enterprise side it's harder. In > particular, while we've seen plenty of IMS equipment support it, > we've seen a very small percentage of PBX's do so, relatively. > > Obviously the same will/can be said of any Martini or SIP-Forum work > - all the devices will have to do Martini (whatever it is) for it to > work. There will be an on-the-wire indication of it, so at least > one can know what the other device does or needs, so that's better, > but at the end of the day as you said the question is whether the > industry will adopt it. In the best case scenario 3GPP, ETSI, SIP- > Forum, and CableLabs will all adopt the Martini work - possibly as > an alternative, or maybe even as the new way. For example the draft- > shaken model is very close/similar to the current 3gpp model. > > -hadriel > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From eburger@standardstrack.com Thu Jan 28 10:32:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3006A28C0E7 for ; Thu, 28 Jan 2010 10:32: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=[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 0381qIJ73Vrf for ; Thu, 28 Jan 2010 10:32:10 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 1CD8F3A6778 for ; Thu, 28 Jan 2010 10:32:10 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.143]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NaZAH-0005wU-7h; Thu, 28 Jan 2010 10:32:25 -0800 From: Eric Burger To: Dean Willis In-Reply-To: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> X-Priority: 1 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> Message-Id: 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, 28 Jan 2010 13:32:25 -0500 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: Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:32:11 -0000 If you ask me (why can't I stay in retirement?), the E.164 situation is not only a simplification, but just about the only thing that is sensible for MARTINI to work on. The E.164 situation is a clear, present, industry-is-begging-for-a- solution problem. It is so pressing, the industry will tell us (the IETF) to get stuffed and do something stupid if we cannot deliver something that is not at its core fundamentally broken. I do not think anyone can have an issue with mechanisms that translate a string of digits into an AOR that might cross domain boundaries. This is the E.164 problem statement. If think everyone (with a brain) SHOULD have issues with a mechanism that magically mungs "sip:eburger@neustar.biz" into "sip:5350@pbx.example.net " while at the same time www.neustar.biz is really a neustar.biz domain. That really would be creating a parallel DNS, which, as one of the major DNS operators, would really, really be "less than ideal" and have a whole host of security and integrity issues. THEREFORE, I would propose that we split this work into two phases: Phase 1: Deliver an E.164 solution, preferably in the next few months, so the industry does not ignore the IETF. Phase 2: Deliver the generic solution in the normal, 3-5 year IETF cycle. This generic solution may or may not encompass E.164 numbers. As Doug Sauder points out, E.164 numbers and their infrastructure are different. Thus a different E.164 registration model from generic SIP URI provisioning models would neither be a burden on industry nor create backwards-compatibility issues for the generic solution. Note that if we do not deliver Phase 1 in a very, very timely manner, the less-than-idea industry solution just might blow up the possibility for the generic solution, which would be considerably less than ideal. On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > > We seem to have an urgent need for a near-term solution for dealing > with the subset of the MARTINI problem that, loosely defined, covers > the "telephone number" problem. > > The typical scenario here is SIP trunking, wherein a SIP Service > Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's PBX (or PBXes). In this model, the SSP maps a whole > bunch of phone numbers to the PBXes. This mapping is somewhat > dynamic, because the PBXes usually have DHCP addresses, and don't > have DNS entries that point A records at the PBX in any sort of > particularly useful way (maybe something like dhcp-10-1-2-3- > example.com). > > So what we need is a way for a PBX, when it reboots (or perhaps > periodically) to say to the SSP "Here I Am; You may now send any > calls for my assigned phone numbers to my current Contact." > > This is indeed a "registration" problem, but it isn't necessarily a > "domain registration problem". The only reason domains get mixed > into this scenario at all is that we sometimes encode telephone > numbers as the user parts of SIP URIs, and those SIP URIs have a > domain part attached to them. > > More interestingly, this problem is a tiny subset of the whole > MARTINI dynamic binding problem, and it potentially can be solved > much more simply than the general problem. > > On today's Interim II call, Richard, Adam and I raised the idea of > dividing our problem space, and taking on a near-term milestone for > delivering a MARTINI solution for registering contacts to a proxy, > where that proxy maps one or more telephone numbers to the contact. > > We certainly intend to go on and tackle the more general domain- > registration problem, but I (and I believe Adam and Richard) believe > that we get a lot out of tackling the telephone-number subset first. > > In particular, we believe that this approach solves many of the > domain "responsibility" questions, simplifies the TLS keying/ > certification model immensely, eliminates the cognitive overload of > using REGISTER to bind a "domain" to a Contact, "route > authentication", and a good many other open issues that plague our > current drafts. > > > Open questions relating to this approach include: > > 1) Do we deal only with E.164 numbers, or do we need to deal with > private-number "phone contexts"? > > 2) D owe need to explicitly encode the telephone numbers being > registered in the REGISTER request (either directly or through some > sort of regexp), or is it adequate to rely on provisioning of the > SSP and PBX (and any UAs) to statically bind the numbers to the PBX > identity, and then dynamically only register the PBX identity to the > PBX contact? > > 3) Can we "register" with a tel: URI as the "To" value? (this seems > to require extending RFC 3261)? Note that "tel:" can express both E. > 164 numbers and private phone-contexts in one format. > > 4) What happens with GRUUs? > > I believe all of these issues are quite tractable, if we accept the > fundamental idea of splitting the phone-number problem off from the > more general domain-registration, and recognize the possibility that > the solutions to the two problem may reasonably be quite different > from each other. > > So, what do you people think? Is it worth trying to drink the > MARTINI elephant one sip at a time, or are we going to treat the > whole thing like a tequila shot and just slam it down? > > -- > Dean > > > > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From dwsauder@dsauder.com Thu Jan 28 10:46:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53FC28C0F7 for ; Thu, 28 Jan 2010 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, 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 34Lh+gLpLLhO for ; Thu, 28 Jan 2010 10:46:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A6D8F28C0F4 for ; Thu, 28 Jan 2010 10:46:09 -0800 (PST) Received: from [192.168.40.95] ([8.18.34.2]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LiDT1-1O5WGi44aB-00nDsR; Thu, 28 Jan 2010 13:46:19 -0500 Message-ID: <4B61DB78.6050405@dsauder.com> Date: Thu, 28 Jan 2010 13:46:16 -0500 From: Doug Sauder User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hadriel Kaplan References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040106050407090705050105" X-Provags-ID: V01U2FsdGVkX1+Kdn0WMaNI8/1mmgT7ONsrGCHTdOeQuGFSIU2 TNSnCRtaXco1wbbu8zeHtcBFI6uTuru4DmPkX9sVK3TG6EhXqI TBBCMbA17waayOiBLBieRkegbBClDUN Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 18:46:10 -0000 This is a multi-part message in MIME format. --------------040106050407090705050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Below... Hadriel Kaplan wrote: > >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf >> Of Doug Sauder >> Sent: Wednesday, January 27, 2010 8:23 PM >> To: Dean Willis >> A key point is that every PBX >> subscriber is provisioned by the SSP, and it is not necessary for a >> REGISTER to tie AORs and contact URIs explicitly. Of course, the SSP >> wants to provide not only PSTN connectivity to their customers, but also >> value-added services, such as services for teleworkers (as was brought up >> earlier on the Martini list). Thus, the explicit provisioning of >> subscribers by the SSP is pretty standard practice. This provides the >> answer to John's question below, about how the "proxy" knows which PBX t >> o route to: it is explicitly provisioned by the SSP. >> > > Yes but we're trying to avoid that - obviously the phone numbers and shared secret password stuff has to be provisioned in the SSP, but we're trying to avoid provisioning the IP:port and transport of the PBX and which specific proxies/SBCs to traverse to reach it (so that, for example, the proxies/SBCs can dynamically change easily). This wouldn't be for large company IP-PBX's really - someone like WalMart or GE or whatever would get white-glove treatment by their SSP's anyway... this is more for the SMB market. > > [DWS] Well, the IP address is not provisioned in most cases, but typically comes from a registration from the PBX. My point was, that the SSP knows the association of phone numbers -- hence subscribers -- to the PBX. It is not necessary for any registration from the PBX to tell the SSP who its subscribers are, or which DIDs it's claiming. > >> 3. I see no need to use a P-Associated-URI header field or similar header >> field in a REGISTER response. I don't see how it is that useful for >> troubleshooting, as the administrative staff of the PBX and has some self- >> service administrative privileges at the SSP. >> > > It was for two reasons: (1) the troubleshooting aspect, where an SMB doesn't have an "administrative staff" for PBX's and even for the SSP it would be nice to get a log/alarm of mismatched numbers a priori, and (2) for the P-CSCF/edge-proxy/SBC's which do P-Asserted-ID assertion or call blocking of unknown/unregistered sources. But I don't know if it's worth it in the end, if folks get hung up over it here. > > -hadriel > --------------040106050407090705050105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Below...

Hadriel Kaplan wrote: 
  
-----Original Message-----
From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf
Of Doug Sauder
Sent: Wednesday, January 27, 2010 8:23 PM
To: Dean Willis
A key point is that every PBX
subscriber is provisioned by the SSP, and it is not necessary for a
REGISTER to tie AORs and contact URIs explicitly.  Of course, the SSP
wants to provide not only PSTN connectivity to their customers, but also
value-added services, such as services for teleworkers (as was brought up
earlier on the Martini list).  Thus, the explicit provisioning of
subscribers by the SSP is pretty standard practice.  This provides the
answer to John's question below, about how the "proxy" knows which PBX t
 o route to: it is explicitly provisioned by the SSP.
    

Yes but we're trying to avoid that - obviously the phone numbers and shared secret password stuff has to be provisioned in the SSP, but we're trying to avoid provisioning the IP:port and transport of the PBX and which specific proxies/SBCs to traverse to reach it (so that, for example, the proxies/SBCs can dynamically change easily).  This wouldn't be for large company IP-PBX's really - someone like WalMart or GE or whatever would get white-glove treatment by their SSP's anyway... this is more for the SMB market.
[DWS] Well, the IP address is not provisioned in most cases, but typically comes from a registration from the PBX.  My point was, that the SSP knows the association of phone numbers -- hence subscribers -- to the PBX.  It is not necessary for any registration from the PBX to tell the SSP who its subscribers are, or which DIDs it's claiming.

  
3. I see no need to use a P-Associated-URI header field or similar header
field in a REGISTER response.  I don't see how it is that useful for
troubleshooting, as the administrative staff of the PBX and has some self-
service administrative privileges at the SSP.
    

It was for two reasons: (1) the troubleshooting aspect, where an SMB doesn't have an "administrative staff" for PBX's and even for the SSP it would be nice to get a log/alarm of mismatched numbers a priori, and (2) for the P-CSCF/edge-proxy/SBC's which do P-Asserted-ID assertion or call blocking of unknown/unregistered sources.  But I don't know if it's worth it in the end, if folks get hung up over it here.

-hadriel
--------------040106050407090705050105-- From spencer@wonderhamster.org Thu Jan 28 13:39:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA263A67B2 for ; Thu, 28 Jan 2010 13:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 FyaC7AnlrsFK for ; Thu, 28 Jan 2010 13:39:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9DD0E3A6844 for ; Thu, 28 Jan 2010 13:39:20 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LyVQs-1NocRN1gYQ-015igg; Thu, 28 Jan 2010 16:39:31 -0500 Message-ID: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> From: "Spencer Dawkins" To: "Eric Burger" , "Dean Willis" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> Date: Thu, 28 Jan 2010 15:39:18 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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++k69ruUMY912l+PGT1DCPi3bD4HA+ZxFrx7y K4B4bZKQqcXDG37oOHoVs5mH+2xUxJsPUK0UE1xTrKbYPugPwV xeSwF/9E74dWUagHQYCfOgnPMlwJgfH5tckpV26lgc= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 21:39:25 -0000 OK, this discussion continues to be lovely. Thanks again for listening to the people you're talking to ("plays well with others" is under-appreciated, once we get out of primary school, but *I* appreciate it!) After reading this thread down through Eric's note below, I have a few requests, as co-chair. We're talking about E.164 numbers like we can easily identify them. My understanding from Tuesday's call was that people on the call thought the only way we could unambiguously know that we had an E.164 number was if we had a tel: URI. If people on this list want to challenge that assertion, this would be a great time to say so - please push back Real Soon Now. If that's true, we're talking about using Tel: URIs. Dean has asserted that this would require an update to 3261. I'm not a genius of 3261, but some of you guys are - could you point us to what you think needs to be updated? My quick read turned up this text in Section 4, page 17: Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). Dean, Is this what you were thinking of? Are there other places that also need to change? As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, Section 2.1, this change would have to go through SIPCORE, because it's an update to 3261. If you know of obvious land mines that we would be walking into if we propose this change, please say so Real Soon Now. (One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the proposal would have to be DISPATCHed on the mailing list in order to do something before IETF 78 - are there OTHERS?) Finally, if you believe that embracing tel: URIs is the wrong thing to do, please say so, Real Soon Now. The milestones that we committed to in http://tools.ietf.org/wg/martini/charters have us adopting a working group SOLUTION draft in January. We're not late yet, but it's the 28th of January in my time zone. If we are late, where late is measured in days, I can live with that, but if we are late, where late is measured in IETF meeting cycles, that's going to be a problem. Thanks, Spencer, as co-chair ----- Original Message ----- From: "Eric Burger" To: "Dean Willis" Cc: Sent: Thursday, January 28, 2010 12:32 PM Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first > If you ask me (why can't I stay in retirement?), the E.164 situation is > not only a simplification, but just about the only thing that is sensible > for MARTINI to work on. > > The E.164 situation is a clear, present, industry-is-begging-for-a- > solution problem. It is so pressing, the industry will tell us (the > IETF) to get stuffed and do something stupid if we cannot deliver > something that is not at its core fundamentally broken. > > I do not think anyone can have an issue with mechanisms that translate a > string of digits into an AOR that might cross domain boundaries. This is > the E.164 problem statement. > > If think everyone (with a brain) SHOULD have issues with a mechanism that > magically mungs "sip:eburger@neustar.biz" into "sip:5350@pbx.example.net " > while at the same time www.neustar.biz is really a neustar.biz domain. > That really would be creating a parallel DNS, which, as one of the major > DNS operators, would really, really be "less than ideal" and have a whole > host of security and integrity issues. > > THEREFORE, I would propose that we split this work into two phases: > Phase 1: Deliver an E.164 solution, preferably in the next few months, > so the industry does not ignore the IETF. > > Phase 2: Deliver the generic solution in the normal, 3-5 year IETF > cycle. This generic solution may or may not encompass E.164 numbers. As > Doug Sauder points out, E.164 numbers and their infrastructure are > different. Thus a different E.164 registration model from generic SIP > URI provisioning models would neither be a burden on industry nor create > backwards-compatibility issues for the generic solution. > > Note that if we do not deliver Phase 1 in a very, very timely manner, the > less-than-idea industry solution just might blow up the possibility for > the generic solution, which would be considerably less than ideal. > > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> >> We seem to have an urgent need for a near-term solution for dealing with >> the subset of the MARTINI problem that, loosely defined, covers the >> "telephone number" problem. >> >> The typical scenario here is SIP trunking, wherein a SIP Service >> Provider (SSP) provides an ISDN-PRI like service over IP to a customer's >> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >> numbers to the PBXes. This mapping is somewhat dynamic, because the >> PBXes usually have DHCP addresses, and don't have DNS entries that point >> A records at the PBX in any sort of particularly useful way (maybe >> something like dhcp-10-1-2-3- example.com). >> >> So what we need is a way for a PBX, when it reboots (or perhaps >> periodically) to say to the SSP "Here I Am; You may now send any calls >> for my assigned phone numbers to my current Contact." >> >> This is indeed a "registration" problem, but it isn't necessarily a >> "domain registration problem". The only reason domains get mixed into >> this scenario at all is that we sometimes encode telephone numbers as >> the user parts of SIP URIs, and those SIP URIs have a domain part >> attached to them. >> >> More interestingly, this problem is a tiny subset of the whole MARTINI >> dynamic binding problem, and it potentially can be solved much more >> simply than the general problem. >> >> On today's Interim II call, Richard, Adam and I raised the idea of >> dividing our problem space, and taking on a near-term milestone for >> delivering a MARTINI solution for registering contacts to a proxy, where >> that proxy maps one or more telephone numbers to the contact. >> >> We certainly intend to go on and tackle the more general domain- >> registration problem, but I (and I believe Adam and Richard) believe >> that we get a lot out of tackling the telephone-number subset first. >> >> In particular, we believe that this approach solves many of the domain >> "responsibility" questions, simplifies the TLS keying/ certification >> model immensely, eliminates the cognitive overload of using REGISTER to >> bind a "domain" to a Contact, "route authentication", and a good many >> other open issues that plague our current drafts. >> >> >> Open questions relating to this approach include: >> >> 1) Do we deal only with E.164 numbers, or do we need to deal with >> private-number "phone contexts"? >> >> 2) D owe need to explicitly encode the telephone numbers being >> registered in the REGISTER request (either directly or through some sort >> of regexp), or is it adequate to rely on provisioning of the SSP and PBX >> (and any UAs) to statically bind the numbers to the PBX identity, and >> then dynamically only register the PBX identity to the PBX contact? >> >> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >> require extending RFC 3261)? Note that "tel:" can express both E. 164 >> numbers and private phone-contexts in one format. >> >> 4) What happens with GRUUs? >> >> I believe all of these issues are quite tractable, if we accept the >> fundamental idea of splitting the phone-number problem off from the more >> general domain-registration, and recognize the possibility that the >> solutions to the two problem may reasonably be quite different from each >> other. >> >> So, what do you people think? Is it worth trying to drink the MARTINI >> elephant one sip at a time, or are we going to treat the whole thing >> like a tequila shot and just slam it down? >> >> -- >> Dean >> >> >> >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From BLINDSAY@nortel.com Thu Jan 28 13:48:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911723A68F4 for ; Thu, 28 Jan 2010 13:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 0gynaHgiO3rR for ; Thu, 28 Jan 2010 13:48:28 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6E6573A67FC for ; Thu, 28 Jan 2010 13:48:28 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o0SLm7E26292; Thu, 28 Jan 2010 21:48:07 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jan 2010 16:48:00 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split: tackletelephone-numberregistration first Thread-Index: AcqgYnuGTtSIFAYXTVqhNn6p5FaPNgAADcYQ References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> From: "Brian Lindsay" To: "Spencer Dawkins" , "Eric Burger" , "Dean Willis" Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 21:48:30 -0000 Hi Spencer, I am not sure if this is going down the path that the actual register request uses a Tel: URI. If so, I don't see why that needs to be the case. The REGISTER itself can still be done per Martini-Shaken with a SIP URI representing the SIP PBX. In fact, I am not sure too much has to change with Martini-Shaken unless you want to enforce use of a Tel URI format for requests sent towards the SIP PBX. Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Thursday, January 28, 2010 4:39 PM To: Eric Burger; Dean Willis Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first OK, this discussion continues to be lovely. Thanks again for listening to the people you're talking to ("plays well with others" is under-appreciated, once we get out of primary school, but *I* appreciate it!) After reading this thread down through Eric's note below, I have a few requests, as co-chair. We're talking about E.164 numbers like we can easily identify them. My understanding from Tuesday's call was that people on the call thought the only way we could unambiguously know that we had an E.164 number was if we had a tel: URI. If people on this list want to challenge that assertion, this would be a great time to say so - please push back Real Soon Now. If that's true, we're talking about using Tel: URIs. Dean has asserted that this would require an update to 3261. I'm not a genius of 3261, but some of you guys are - could you point us to what you think needs to be updated? My quick read turned up this text in Section 4, page 17: Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). Dean, Is this what you were thinking of? Are there other places that also need to change? As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, Section 2.1, this change would have to go through SIPCORE, because it's an update to 3261. If you know of obvious land mines that we would be walking into if we propose this change, please say so Real Soon Now. (One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the proposal would have to be DISPATCHed on the mailing list in order to do something before IETF 78 - are there OTHERS?) Finally, if you believe that embracing tel: URIs is the wrong thing to do, please say so, Real Soon Now. The milestones that we committed to in http://tools.ietf.org/wg/martini/charters have us adopting a working group SOLUTION draft in January. We're not late yet, but it's the 28th of January in my time zone. If we are late, where late is measured in days, I can live with that, but if we are late, where late is measured in IETF meeting cycles, that's going to be a problem. Thanks, Spencer, as co-chair ----- Original Message ----- From: "Eric Burger" To: "Dean Willis" Cc: Sent: Thursday, January 28, 2010 12:32 PM Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first > If you ask me (why can't I stay in retirement?), the E.164 situation is > not only a simplification, but just about the only thing that is sensible > for MARTINI to work on. > > The E.164 situation is a clear, present, industry-is-begging-for-a- > solution problem. It is so pressing, the industry will tell us (the > IETF) to get stuffed and do something stupid if we cannot deliver > something that is not at its core fundamentally broken. > > I do not think anyone can have an issue with mechanisms that translate a > string of digits into an AOR that might cross domain boundaries. This is > the E.164 problem statement. > > If think everyone (with a brain) SHOULD have issues with a mechanism that > magically mungs "sip:eburger@neustar.biz" into "sip:5350@pbx.example.net " > while at the same time www.neustar.biz is really a neustar.biz domain. > That really would be creating a parallel DNS, which, as one of the major > DNS operators, would really, really be "less than ideal" and have a whole > host of security and integrity issues. > > THEREFORE, I would propose that we split this work into two phases: > Phase 1: Deliver an E.164 solution, preferably in the next few months, > so the industry does not ignore the IETF. > > Phase 2: Deliver the generic solution in the normal, 3-5 year IETF > cycle. This generic solution may or may not encompass E.164 numbers. As > Doug Sauder points out, E.164 numbers and their infrastructure are > different. Thus a different E.164 registration model from generic SIP > URI provisioning models would neither be a burden on industry nor create > backwards-compatibility issues for the generic solution. > > Note that if we do not deliver Phase 1 in a very, very timely manner, the > less-than-idea industry solution just might blow up the possibility for > the generic solution, which would be considerably less than ideal. > > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> >> We seem to have an urgent need for a near-term solution for dealing with >> the subset of the MARTINI problem that, loosely defined, covers the >> "telephone number" problem. >> >> The typical scenario here is SIP trunking, wherein a SIP Service >> Provider (SSP) provides an ISDN-PRI like service over IP to a customer's >> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >> numbers to the PBXes. This mapping is somewhat dynamic, because the >> PBXes usually have DHCP addresses, and don't have DNS entries that point >> A records at the PBX in any sort of particularly useful way (maybe >> something like dhcp-10-1-2-3- example.com). >> >> So what we need is a way for a PBX, when it reboots (or perhaps >> periodically) to say to the SSP "Here I Am; You may now send any calls >> for my assigned phone numbers to my current Contact." >> >> This is indeed a "registration" problem, but it isn't necessarily a >> "domain registration problem". The only reason domains get mixed into >> this scenario at all is that we sometimes encode telephone numbers as >> the user parts of SIP URIs, and those SIP URIs have a domain part >> attached to them. >> >> More interestingly, this problem is a tiny subset of the whole MARTINI >> dynamic binding problem, and it potentially can be solved much more >> simply than the general problem. >> >> On today's Interim II call, Richard, Adam and I raised the idea of >> dividing our problem space, and taking on a near-term milestone for >> delivering a MARTINI solution for registering contacts to a proxy, where >> that proxy maps one or more telephone numbers to the contact. >> >> We certainly intend to go on and tackle the more general domain- >> registration problem, but I (and I believe Adam and Richard) believe >> that we get a lot out of tackling the telephone-number subset first. >> >> In particular, we believe that this approach solves many of the domain >> "responsibility" questions, simplifies the TLS keying/ certification >> model immensely, eliminates the cognitive overload of using REGISTER to >> bind a "domain" to a Contact, "route authentication", and a good many >> other open issues that plague our current drafts. >> >> >> Open questions relating to this approach include: >> >> 1) Do we deal only with E.164 numbers, or do we need to deal with >> private-number "phone contexts"? >> >> 2) D owe need to explicitly encode the telephone numbers being >> registered in the REGISTER request (either directly or through some sort >> of regexp), or is it adequate to rely on provisioning of the SSP and PBX >> (and any UAs) to statically bind the numbers to the PBX identity, and >> then dynamically only register the PBX identity to the PBX contact? >> >> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >> require extending RFC 3261)? Note that "tel:" can express both E. 164 >> numbers and private phone-contexts in one format. >> >> 4) What happens with GRUUs? >> >> I believe all of these issues are quite tractable, if we accept the >> fundamental idea of splitting the phone-number problem off from the more >> general domain-registration, and recognize the possibility that the >> solutions to the two problem may reasonably be quite different from each >> other. >> >> So, what do you people think? Is it worth trying to drink the MARTINI >> elephant one sip at a time, or are we going to treat the whole thing >> like a tequila shot and just slam it down? >> >> -- >> Dean >> >> >> >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From spencer@wonderhamster.org Thu Jan 28 13:58:29 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F99A3A67E1 for ; Thu, 28 Jan 2010 13:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 O+wdg-GLBfb4 for ; Thu, 28 Jan 2010 13:58:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B49BB3A677C for ; Thu, 28 Jan 2010 13:58:27 -0800 (PST) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LyFqf-1NpSHV2zP3-015DCr; Thu, 28 Jan 2010 16:58:46 -0500 Message-ID: From: "Spencer Dawkins" To: "Brian Lindsay" , "Eric Burger" , "Dean Willis" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> Date: Thu, 28 Jan 2010 15:58:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX19+RGc1INQLoMsWpOw7SPXtL/gFTc5sPw3AqZd h7nV82gCPlTAupLTNdfPROLIUljiMJMNe1Wt+yYMcBdFoO/0g8 +FOFPGvBlq3u0zCUJvBqsXP1TlUSGO38WPhMiG7R1M= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 21:58:29 -0000 Hi, Brian, Thanks for the quick feedback. I'm mostly asking if I'm reading where we are going correctly (I GOTTA get the draft minutes out from that call!). This is kind of twisty-little-passages-all-alike/different (for those of you that remember the "adventure" game in the early 1980s), but I'm trying to follow the chain. Where I thought we were, was that we didn't have a coherent story for how we get a call from outside the service provider, to the service provider, to the SIP-PBX, and I've heard a bunch of smart guys talk for a long time on a number of occasions about how that might work/not work, usually ending with "but if this was limited to E.164 numbers, a lot of these problems would go away". So I'm trying to laces comments from the call that I remember together, and see what the resulting tapestry looks like. Tell you what. I'll go work on draft minutes and stop typing e-mail, and we'll see if that works better :D Spencer ----- Original Message ----- From: "Brian Lindsay" To: "Spencer Dawkins" ; "Eric Burger" ; "Dean Willis" Cc: Sent: Thursday, January 28, 2010 3:48 PM Subject: RE: [martini] Proposed work split: tackletelephone-numberregistration first Hi Spencer, I am not sure if this is going down the path that the actual register request uses a Tel: URI. If so, I don't see why that needs to be the case. The REGISTER itself can still be done per Martini-Shaken with a SIP URI representing the SIP PBX. In fact, I am not sure too much has to change with Martini-Shaken unless you want to enforce use of a Tel URI format for requests sent towards the SIP PBX. Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Thursday, January 28, 2010 4:39 PM To: Eric Burger; Dean Willis Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackletelephone-numberregistration first OK, this discussion continues to be lovely. Thanks again for listening to the people you're talking to ("plays well with others" is under-appreciated, once we get out of primary school, but *I* appreciate it!) After reading this thread down through Eric's note below, I have a few requests, as co-chair. We're talking about E.164 numbers like we can easily identify them. My understanding from Tuesday's call was that people on the call thought the only way we could unambiguously know that we had an E.164 number was if we had a tel: URI. If people on this list want to challenge that assertion, this would be a great time to say so - please push back Real Soon Now. If that's true, we're talking about using Tel: URIs. Dean has asserted that this would require an update to 3261. I'm not a genius of 3261, but some of you guys are - could you point us to what you think needs to be updated? My quick read turned up this text in Section 4, page 17: Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). Dean, Is this what you were thinking of? Are there other places that also need to change? As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, Section 2.1, this change would have to go through SIPCORE, because it's an update to 3261. If you know of obvious land mines that we would be walking into if we propose this change, please say so Real Soon Now. (One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the proposal would have to be DISPATCHed on the mailing list in order to do something before IETF 78 - are there OTHERS?) Finally, if you believe that embracing tel: URIs is the wrong thing to do, please say so, Real Soon Now. The milestones that we committed to in http://tools.ietf.org/wg/martini/charters have us adopting a working group SOLUTION draft in January. We're not late yet, but it's the 28th of January in my time zone. If we are late, where late is measured in days, I can live with that, but if we are late, where late is measured in IETF meeting cycles, that's going to be a problem. Thanks, Spencer, as co-chair ----- Original Message ----- From: "Eric Burger" To: "Dean Willis" Cc: Sent: Thursday, January 28, 2010 12:32 PM Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first > If you ask me (why can't I stay in retirement?), the E.164 situation is > not only a simplification, but just about the only thing that is sensible > for MARTINI to work on. > > The E.164 situation is a clear, present, industry-is-begging-for-a- > solution problem. It is so pressing, the industry will tell us (the > IETF) to get stuffed and do something stupid if we cannot deliver > something that is not at its core fundamentally broken. > > I do not think anyone can have an issue with mechanisms that translate a > string of digits into an AOR that might cross domain boundaries. This is > the E.164 problem statement. > > If think everyone (with a brain) SHOULD have issues with a mechanism that > magically mungs "sip:eburger@neustar.biz" into "sip:5350@pbx.example.net " > while at the same time www.neustar.biz is really a neustar.biz domain. > That really would be creating a parallel DNS, which, as one of the major > DNS operators, would really, really be "less than ideal" and have a whole > host of security and integrity issues. > > THEREFORE, I would propose that we split this work into two phases: > Phase 1: Deliver an E.164 solution, preferably in the next few months, > so the industry does not ignore the IETF. > > Phase 2: Deliver the generic solution in the normal, 3-5 year IETF > cycle. This generic solution may or may not encompass E.164 numbers. As > Doug Sauder points out, E.164 numbers and their infrastructure are > different. Thus a different E.164 registration model from generic SIP > URI provisioning models would neither be a burden on industry nor create > backwards-compatibility issues for the generic solution. > > Note that if we do not deliver Phase 1 in a very, very timely manner, the > less-than-idea industry solution just might blow up the possibility for > the generic solution, which would be considerably less than ideal. > > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> >> We seem to have an urgent need for a near-term solution for dealing with >> the subset of the MARTINI problem that, loosely defined, covers the >> "telephone number" problem. >> >> The typical scenario here is SIP trunking, wherein a SIP Service >> Provider (SSP) provides an ISDN-PRI like service over IP to a customer's >> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >> numbers to the PBXes. This mapping is somewhat dynamic, because the >> PBXes usually have DHCP addresses, and don't have DNS entries that point >> A records at the PBX in any sort of particularly useful way (maybe >> something like dhcp-10-1-2-3- example.com). >> >> So what we need is a way for a PBX, when it reboots (or perhaps >> periodically) to say to the SSP "Here I Am; You may now send any calls >> for my assigned phone numbers to my current Contact." >> >> This is indeed a "registration" problem, but it isn't necessarily a >> "domain registration problem". The only reason domains get mixed into >> this scenario at all is that we sometimes encode telephone numbers as >> the user parts of SIP URIs, and those SIP URIs have a domain part >> attached to them. >> >> More interestingly, this problem is a tiny subset of the whole MARTINI >> dynamic binding problem, and it potentially can be solved much more >> simply than the general problem. >> >> On today's Interim II call, Richard, Adam and I raised the idea of >> dividing our problem space, and taking on a near-term milestone for >> delivering a MARTINI solution for registering contacts to a proxy, where >> that proxy maps one or more telephone numbers to the contact. >> >> We certainly intend to go on and tackle the more general domain- >> registration problem, but I (and I believe Adam and Richard) believe >> that we get a lot out of tackling the telephone-number subset first. >> >> In particular, we believe that this approach solves many of the domain >> "responsibility" questions, simplifies the TLS keying/ certification >> model immensely, eliminates the cognitive overload of using REGISTER to >> bind a "domain" to a Contact, "route authentication", and a good many >> other open issues that plague our current drafts. >> >> >> Open questions relating to this approach include: >> >> 1) Do we deal only with E.164 numbers, or do we need to deal with >> private-number "phone contexts"? >> >> 2) D owe need to explicitly encode the telephone numbers being >> registered in the REGISTER request (either directly or through some sort >> of regexp), or is it adequate to rely on provisioning of the SSP and PBX >> (and any UAs) to statically bind the numbers to the PBX identity, and >> then dynamically only register the PBX identity to the PBX contact? >> >> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >> require extending RFC 3261)? Note that "tel:" can express both E. 164 >> numbers and private phone-contexts in one format. >> >> 4) What happens with GRUUs? >> >> I believe all of these issues are quite tractable, if we accept the >> fundamental idea of splitting the phone-number problem off from the more >> general domain-registration, and recognize the possibility that the >> solutions to the two problem may reasonably be quite different from each >> other. >> >> So, what do you people think? Is it worth trying to drink the MARTINI >> elephant one sip at a time, or are we going to treat the whole thing >> like a tequila shot and just slam it down? >> >> -- >> Dean >> >> >> >> >> >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From drage@alcatel-lucent.com Thu Jan 28 14:00:55 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651773A6951 for ; Thu, 28 Jan 2010 14:00:55 -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=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8uIwfY-LGJj for ; Thu, 28 Jan 2010 14:00:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 335213A6842 for ; Thu, 28 Jan 2010 14:00:53 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o0SM1Bg6010055 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Jan 2010 23:01:11 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 28 Jan 2010 23:01:11 +0100 From: "DRAGE, Keith (Keith)" To: Eric Burger , "bruno.chatras@orange-ftgroup.com" Date: Thu, 28 Jan 2010 23:01:09 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: AcqgRn0axvrrI/SPTqGXtbAxhtsHpgAHqaIg Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> <994FE530-28D0-4686-AF35-71AD5A0E1872@standardstrack.com> In-Reply-To: <994FE530-28D0-4686-AF35-71AD5A0E1872@standardstrack.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.64 on 155.132.188.84 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:00:55 -0000 Gee great - Lets all just throw in a few unspecific comments about the non-= interoperability of 3GPP specs and we'll win all the IETF arguments. I think you'll find it is the people who use the specs, be it IETF, 3GPP or= whatever, that bend the rules that cause those problems.=20 Keith=20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Thursday, January 28, 2010 6:20 PM > To: bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-number registrationfirst >=20 > More to the point, we have absolutely no intention of doing=20 > the ETSI/ 3GPP thing of creating something that looks almost=20 > compatible with SIP, but really is not. The mechanism here,=20 > while it needs MARTINI- aware devices to be aware of MARTINI=20 > (no sequitur of the day), non- MARTINI-aware devices will=20 > still be able to communicate with MARTINI- aware devices, and=20 > vice-versa. The same is NOT true of the ETSI/3GPP approach. >=20 > On Jan 28, 2010, at 12:24 PM, Hadriel Kaplan wrote: >=20 > > Hi Bruno, comments inline... > > > >> -----Original Message----- > >> From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On=20 > >> Behalf Of bruno.chatras@orange-ftgroup.com > >> Sent: Thursday, January 28, 2010 5:06 AM > >> > >> Looking to this proposal, another question comes to my=20 > mind. There=20 > >> is something that I don't understand from an Industry viewpoint. > >> > >> - 3GPP/ETSI have defined a solution that applies to all types of=20 > >> identities (E.164 numbers, private numbers and email-style=20 > URI). For=20 > >> various reasons this solution is not deemed suitable by=20 > the MARTINI=20 > >> community. > > > > Martini was instigated from work we were doing in SIP-Forum, and in=20 > > the SIP-Forum at one point we were nearly identical to the=20 > 3gpp/etsi=20 > > mechanism, but technical objections and issues were raised, which=20 > > drove us to go to the IETF. The 50,000ft view of the=20 > issues were that=20 > > the 3gpp/etsi model "works" as long as everyone's on the=20 > same page -=20 > > that they all happen to be provisioned to implement the exact same=20 > > procedures from the same version of the specs. They all=20 > have to know=20 > > that the "normal" procedures of 3261 are not being=20 > followed, and they=20 > > have to know which procedures are being followed, without any=20 > > on-the-wire indication that or what they are. For example,=20 > they have=20 > > to know that the request-URI is or is not going to be the=20 > registered=20 > > contact (it can be either way, just based on a provisioned field). > > > > That's all fine on the SSP-side, because presumably they=20 > control all=20 > > their own equipment. But on the Enterprise side it's harder. In=20 > > particular, while we've seen plenty of IMS equipment=20 > support it, we've=20 > > seen a very small percentage of PBX's do so, relatively. > > > > Obviously the same will/can be said of any Martini or SIP-Forum work > > - all the devices will have to do Martini (whatever it is)=20 > for it to=20 > > work. There will be an on-the-wire indication of it, so at=20 > least one=20 > > can know what the other device does or needs, so that's=20 > better, but at=20 > > the end of the day as you said the question is whether the industry=20 > > will adopt it. In the best case scenario 3GPP, ETSI, SIP-=20 > Forum, and=20 > > CableLabs will all adopt the Martini work - possibly as an=20 > > alternative, or maybe even as the new way. For example the draft-=20 > > shaken model is very close/similar to the current 3gpp model. > > > > -hadriel > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From adam@nostrum.com Thu Jan 28 14:33:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFDD3A67B2 for ; Thu, 28 Jan 2010 14:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 FCt0aNOWeXlR for ; Thu, 28 Jan 2010 14:33:04 -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 99BAF3A68A9 for ; Thu, 28 Jan 2010 14:33:03 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0SMXFRc076577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 16:33:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6210AB.1050309@nostrum.com> Date: Thu, 28 Jan 2010 16:33:15 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> Content-Type: multipart/alternative; boundary="------------020708060608020400010507" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:33:05 -0000 This is a multi-part message in MIME format. --------------020708060608020400010507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/28/10 3:39 PM, Spencer Dawkins wrote: > We're talking about E.164 numbers like we can easily identify them. My > understanding from Tuesday's call was that people on the call thought the > only way we could unambiguously know that we had an E.164 number was > if we > had a tel: URI. If people on this list want to challenge that > assertion, this would > be a great time to say so - please push back Real Soon Now. I believe that's true. A large part of what we've been arguing over relates directly to questions around who is responsible for which actions when domains are involved. It is squarely the domains themselves that cause so much consternation and confusion in this context, and any simplifications that arise from limiting the scope to E.164 numbers are predicated _completely_ on the elimination of domains. As far as I can tell, we really have two approaches we can consider: * Use tel: URIs. Their lack of domains eliminates domain-related issues. * Define a new sip: URI parameter that effectively means "the user portion is an E.164 number that can be evaluated by anyone in the world regardless of the domain attached to it." This isn't quite the same thing as "user=phone," although they do seem superficially similar. We would need to define rules around this parameter that effectively say, "if you see this parameter on a URI, you are free to discard the domain and act as responsible for the URI" (this is the material difference from "user=phone"). I like the first one because it's already specified. /a --------------020708060608020400010507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/28/10 3:39 PM, Spencer Dawkins wrote:
We're talking about E.164 numbers like we can easily identify them. My
understanding from Tuesday's call was that people on the call thought the
only way we could unambiguously know that we had an E.164 number was if we
had a tel: URI. If people on this list want to challenge that assertion, this would
be a great time to say so - please push back Real Soon Now.

I believe that's true. A large part of what we've been arguing over relates directly to questions around who is responsible for which actions when domains are involved. It is squarely the domains themselves that cause so much consternation and confusion in this context, and any simplifications that arise from limiting the scope to E.164 numbers are predicated _completely_ on the elimination of domains.

As far as I can tell, we really have two approaches we can consider:
  • Use tel: URIs. Their lack of domains eliminates domain-related issues.

  • Define a new sip: URI parameter that effectively means "the user portion is an E.164 number that can be evaluated by anyone in the world regardless of the domain attached to it." This isn't quite the same thing as "user=phone," although they do seem superficially similar. We would need to define rules around this parameter that effectively say, "if you see this parameter on a URI, you are free to discard the domain and act as responsible for the URI" (this is the material difference from "user=phone").

I like the first one because it's already specified.

/a
--------------020708060608020400010507-- From adam@nostrum.com Thu Jan 28 14:48:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279E13A68B3 for ; Thu, 28 Jan 2010 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045, 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 HRo7iXPDFk1l for ; Thu, 28 Jan 2010 14:48:01 -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 059C83A6882 for ; Thu, 28 Jan 2010 14:48:00 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0SMmImk077648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 16:48:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B621432.8040901@nostrum.com> Date: Thu, 28 Jan 2010 16:48:18 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 22:48:02 -0000 On 1/28/10 4:05 AM, bruno.chatras@orange-ftgroup.com wrote: > I'm wondering what could be the motivation of the Industry to adopt the E.164-only solution as a near-term solution rather than the 3GPP/ETSI solution? This can only happen if the E-164 solution has very strong benefits and the 3GPP/ETSI solution has major flaws that prevents its implementation. > It does, and we've been discussing them. The 3GPP approach demonstrably works in walled gardens modeled after the IMS architecture. However, we are not the Walled Garden Engineering Task Force, so we need to ensure it works on the Internet at large, including a multitude of architectures that don't resemble IMS in any useful way. As far as I can tell, SIPForum is antsy to get something specified now, even if its very limited in scope. We determined on the call that many of the really controversial issues become inapplicable if we're willing to accept certain restrictions, all of which require scoping the work to E.164 numbers. I suspect this is true, and that we can knock out a solution very quickly within this tightly constrained scope. And, to be sure, the scope restriction is somewhat tighter than just "E.164 numbers" -- it actually relates predominantly to the elimination of domains in the SSP-PBX signaling (which is possibly only if the user portion is universally unique, as in the case of E.164 numbers). /a From SRS0=S2jTwu=JO=standardstrack.com=eburger@srs.bis.na.blackberry.com Thu Jan 28 17:19:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676DF3A67A5 for ; Thu, 28 Jan 2010 17:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 VavszIB8Yn0Q for ; Thu, 28 Jan 2010 17:19:30 -0800 (PST) Received: from smtp06.bis.na.blackberry.com (smtp06.bis.na.blackberry.com [216.9.248.53]) by core3.amsl.com (Postfix) with ESMTP id BC6783A6407 for ; Thu, 28 Jan 2010 17:19:29 -0800 (PST) Received: from bda380.bisx.prod.on.blackberry (bda380.bisx.prod.on.blackberry [172.20.234.80]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id o0T1KbPZ024271 for ; Fri, 29 Jan 2010 01:20:37 GMT Received: from bda380.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda380.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id o0T1JlWN013681 for ; Fri, 29 Jan 2010 01:19:48 GMT X-rim-org-msg-ref-id: 806708904 Message-ID: <806708904-1264727986-cardhu_decombobulator_blackberry.rim.net-723508768-@bda849.bisx.prod.on.blackberry> X-Priority: Normal References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com><4B6210AB.1050309@nostrum.com> In-Reply-To: <4B6210AB.1050309@nostrum.com> Sensitivity: Normal Importance: Normal To: martini@IETF.org From: "eburger" Date: Fri, 29 Jan 2010 01:19:48 +0000 Content-Type: multipart/alternative; boundary="part15516-boundary-518362682-661752583" MIME-Version: 1.0 Subject: Re: [martini] Proposed work split: tackle telephone-numberregistrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eburger@standardstrack.com List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 01:20:40 -0000 --part15516-boundary-518362682-661752583 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" QWdyZWVkLiANCg0KLS0NCkVyaWMgQnVyZ2VyDQoNClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNl OyBzb3JyeSBpZiB0ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAgU2VlIDxo dHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlPiBmb3IgbW9yZSBpbmZv cm1hdGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2gg PGFkYW1Abm9zdHJ1bS5jb20+DQpEYXRlOiBUaHUsIDI4IEphbiAyMDEwIDE2OjMzOjE1IA0KVG86 IFNwZW5jZXIgRGF3a2luczxzcGVuY2VyQHdvbmRlcmhhbXN0ZXIub3JnPg0KQ2M6IEVyaWMgQnVy Z2VyPGVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tPjsgRGVhbiBXaWxsaXM8ZGVhbi53aWxsaXNA c29mdGFybW9yLmNvbT47IDxtYXJ0aW5pQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFttYXJ0aW5p XSBQcm9wb3NlZCB3b3JrIHNwbGl0OiB0YWNrbGUJdGVsZXBob25lLW51bWJlcnJlZ2lzdHJhdGlv bg0KIGZpcnN0DQoNCk9uIDEvMjgvMTAgMzozOSBQTSwgU3BlbmNlciBEYXdraW5zIHdyb3RlOg0K PiBXZSdyZSB0YWxraW5nIGFib3V0IEUuMTY0IG51bWJlcnMgbGlrZSB3ZSBjYW4gZWFzaWx5IGlk ZW50aWZ5IHRoZW0uIE15DQo+IHVuZGVyc3RhbmRpbmcgZnJvbSBUdWVzZGF5J3MgY2FsbCB3YXMg dGhhdCBwZW9wbGUgb24gdGhlIGNhbGwgdGhvdWdodCB0aGUNCj4gb25seSB3YXkgd2UgY291bGQg dW5hbWJpZ3VvdXNseSBrbm93IHRoYXQgd2UgaGFkIGFuIEUuMTY0IG51bWJlciB3YXMgDQo+IGlm IHdlDQo+IGhhZCBhIHRlbDogVVJJLiBJZiBwZW9wbGUgb24gdGhpcyBsaXN0IHdhbnQgdG8gY2hh bGxlbmdlIHRoYXQgDQo+IGFzc2VydGlvbiwgdGhpcyB3b3VsZA0KPiBiZSBhIGdyZWF0IHRpbWUg dG8gc2F5IHNvIC0gcGxlYXNlIHB1c2ggYmFjayBSZWFsIFNvb24gTm93Lg0KDQpJIGJlbGlldmUg dGhhdCdzIHRydWUuIEEgbGFyZ2UgcGFydCBvZiB3aGF0IHdlJ3ZlIGJlZW4gYXJndWluZyBvdmVy IA0KcmVsYXRlcyBkaXJlY3RseSB0byBxdWVzdGlvbnMgYXJvdW5kIHdobyBpcyByZXNwb25zaWJs ZSBmb3Igd2hpY2ggDQphY3Rpb25zIHdoZW4gZG9tYWlucyBhcmUgaW52b2x2ZWQuIEl0IGlzIHNx dWFyZWx5IHRoZSBkb21haW5zIHRoZW1zZWx2ZXMgDQp0aGF0IGNhdXNlIHNvIG11Y2ggY29uc3Rl cm5hdGlvbiBhbmQgY29uZnVzaW9uIGluIHRoaXMgY29udGV4dCwgYW5kIGFueSANCnNpbXBsaWZp Y2F0aW9ucyB0aGF0IGFyaXNlIGZyb20gbGltaXRpbmcgdGhlIHNjb3BlIHRvIEUuMTY0IG51bWJl cnMgYXJlIA0KcHJlZGljYXRlZCBfY29tcGxldGVseV8gb24gdGhlIGVsaW1pbmF0aW9uIG9mIGRv bWFpbnMuDQoNCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB3ZSByZWFsbHkgaGF2ZSB0d28gYXBwcm9h Y2hlcyB3ZSBjYW4gY29uc2lkZXI6DQoNCiAgICAqIFVzZSB0ZWw6IFVSSXMuIFRoZWlyIGxhY2sg b2YgZG9tYWlucyBlbGltaW5hdGVzIGRvbWFpbi1yZWxhdGVkIGlzc3Vlcy4NCg0KICAgICogRGVm aW5lIGEgbmV3IHNpcDogVVJJIHBhcmFtZXRlciB0aGF0IGVmZmVjdGl2ZWx5IG1lYW5zICJ0aGUg dXNlcg0KICAgICAgcG9ydGlvbiBpcyBhbiBFLjE2NCBudW1iZXIgdGhhdCBjYW4gYmUgZXZhbHVh dGVkIGJ5IGFueW9uZSBpbiB0aGUNCiAgICAgIHdvcmxkIHJlZ2FyZGxlc3Mgb2YgdGhlIGRvbWFp biBhdHRhY2hlZCB0byBpdC4iIFRoaXMgaXNuJ3QgcXVpdGUNCiAgICAgIHRoZSBzYW1lIHRoaW5n IGFzICJ1c2VyPXBob25lLCIgYWx0aG91Z2ggdGhleSBkbyBzZWVtDQogICAgICBzdXBlcmZpY2lh bGx5IHNpbWlsYXIuIFdlIHdvdWxkIG5lZWQgdG8gZGVmaW5lIHJ1bGVzIGFyb3VuZCB0aGlzDQog ICAgICBwYXJhbWV0ZXIgdGhhdCBlZmZlY3RpdmVseSBzYXksICJpZiB5b3Ugc2VlIHRoaXMgcGFy YW1ldGVyIG9uIGENCiAgICAgIFVSSSwgeW91IGFyZSBmcmVlIHRvIGRpc2NhcmQgdGhlIGRvbWFp biBhbmQgYWN0IGFzIHJlc3BvbnNpYmxlIGZvcg0KICAgICAgdGhlIFVSSSIgKHRoaXMgaXMgdGhl IG1hdGVyaWFsIGRpZmZlcmVuY2UgZnJvbSAidXNlcj1waG9uZSIpLg0KDQoNCkkgbGlrZSB0aGUg Zmlyc3Qgb25lIGJlY2F1c2UgaXQncyBhbHJlYWR5IHNwZWNpZmllZC4NCg0KL2ENCg0K --part15516-boundary-518362682-661752583 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs Ly9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiDQogaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiPkFncmVlZC4gPHA+DTxici8+LS08YnIvPkVy aWMgQnVyZ2VyPGJyLz48YnIvPlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlOyBzb3JyeSBpZiB0 ZXJzZS4gQWxsIG1vYmlsZSB1c2VycyBuZWVkIGxlbW9uYWRlLiAgU2VlICZsdDtodHRwOi8vd3d3 LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlJmd0OyBmb3IgbW9yZSBpbmZvcm1hdGlv bi48L3A+PGhyLz48ZGl2PjxiPkZyb206IDwvYj4gQWRhbSBSb2FjaCAmbHQ7YWRhbUBub3N0cnVt LmNvbSZndDsNCjwvZGl2PjxkaXY+PGI+RGF0ZTogPC9iPlRodSwgMjggSmFuIDIwMTAgMTY6MzM6 MTUgLTA2MDA8L2Rpdj48ZGl2PjxiPlRvOiA8L2I+U3BlbmNlciBEYXdraW5zJmx0O3NwZW5jZXJA d29uZGVyaGFtc3Rlci5vcmcmZ3Q7PC9kaXY+PGRpdj48Yj5DYzogPC9iPkVyaWMgQnVyZ2VyJmx0 O2VidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tJmd0OzsgRGVhbiBXaWxsaXMmbHQ7ZGVhbi53aWxs aXNAc29mdGFybW9yLmNvbSZndDs7ICZsdDttYXJ0aW5pQGlldGYub3JnJmd0OzwvZGl2PjxkaXY+ PGI+U3ViamVjdDogPC9iPlJlOiBbbWFydGluaV0gUHJvcG9zZWQgd29yayBzcGxpdDogdGFja2xl CXRlbGVwaG9uZS1udW1iZXJyZWdpc3RyYXRpb24NCiBmaXJzdDwvZGl2PjxkaXY+PGJyLz48L2Rp dj4NCk9uIDEvMjgvMTAgMzozOSBQTSwgU3BlbmNlciBEYXdraW5zIHdyb3RlOg0KPGJsb2NrcXVv dGUgY2l0ZT0ibWlkOjEzMDg5NUZERTFCNDQ4OEM4MjE1OEQwNTFBMUQ5NEQ5QGNoaW5hLmh1YXdl aS5jb20iDQogdHlwZT0iY2l0ZSI+V2UncmUgdGFsa2luZyBhYm91dCBFLjE2NCBudW1iZXJzIGxp a2Ugd2UgY2FuIGVhc2lseQ0KaWRlbnRpZnkgdGhlbS4gTXkNCiAgPGJyPg0KdW5kZXJzdGFuZGlu ZyBmcm9tIFR1ZXNkYXkncyBjYWxsIHdhcyB0aGF0IHBlb3BsZSBvbiB0aGUgY2FsbCB0aG91Z2h0 DQp0aGUNCiAgPGJyPg0Kb25seSB3YXkgd2UgY291bGQgdW5hbWJpZ3VvdXNseSBrbm93IHRoYXQg d2UgaGFkIGFuIEUuMTY0IG51bWJlciB3YXMgaWYNCndlDQogIDxicj4NCmhhZCBhIHRlbDogVVJJ LiBJZiBwZW9wbGUgb24gdGhpcyBsaXN0IHdhbnQgdG8gY2hhbGxlbmdlIHRoYXQNCmFzc2VydGlv biwgdGhpcyB3b3VsZA0KICA8YnI+DQpiZSBhIGdyZWF0IHRpbWUgdG8gc2F5IHNvIC0gcGxlYXNl IHB1c2ggYmFjayBSZWFsIFNvb24gTm93Lg0KICA8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQpJ IGJlbGlldmUgdGhhdCdzIHRydWUuIEEgbGFyZ2UgcGFydCBvZiB3aGF0IHdlJ3ZlIGJlZW4gYXJn dWluZyBvdmVyDQpyZWxhdGVzIGRpcmVjdGx5IHRvIHF1ZXN0aW9ucyBhcm91bmQgd2hvIGlzIHJl c3BvbnNpYmxlIGZvciB3aGljaA0KYWN0aW9ucyB3aGVuIGRvbWFpbnMgYXJlIGludm9sdmVkLiBJ dCBpcyBzcXVhcmVseSB0aGUgZG9tYWlucw0KdGhlbXNlbHZlcyB0aGF0IGNhdXNlIHNvIG11Y2gg Y29uc3Rlcm5hdGlvbiBhbmQgY29uZnVzaW9uIGluIHRoaXMNCmNvbnRleHQsIGFuZCBhbnkgc2lt cGxpZmljYXRpb25zIHRoYXQgYXJpc2UgZnJvbSBsaW1pdGluZyB0aGUgc2NvcGUgdG8NCkUuMTY0 IG51bWJlcnMgYXJlIHByZWRpY2F0ZWQgX2NvbXBsZXRlbHlfIG9uIHRoZSBlbGltaW5hdGlvbiBv ZiBkb21haW5zLjxicj4NCjxicj4NCkFzIGZhciBhcyBJIGNhbiB0ZWxsLCB3ZSByZWFsbHkgaGF2 ZSB0d28gYXBwcm9hY2hlcyB3ZSBjYW4gY29uc2lkZXI6PGJyPg0KPHVsPg0KICA8bGk+VXNlIHRl bDogVVJJcy4gVGhlaXIgbGFjayBvZiBkb21haW5zIGVsaW1pbmF0ZXMgZG9tYWluLXJlbGF0ZWQN Cmlzc3Vlcy48YnI+DQogICAgPGJyPg0KICA8L2xpPg0KICA8bGk+RGVmaW5lIGEgbmV3IHNpcDog VVJJIHBhcmFtZXRlciB0aGF0IGVmZmVjdGl2ZWx5IG1lYW5zICJ0aGUgdXNlcg0KcG9ydGlvbiBp cyBhbiBFLjE2NCBudW1iZXIgdGhhdCBjYW4gYmUgZXZhbHVhdGVkIGJ5IGFueW9uZSBpbiB0aGUg d29ybGQNCnJlZ2FyZGxlc3Mgb2YgdGhlIGRvbWFpbiBhdHRhY2hlZCB0byBpdC4iIFRoaXMgaXNu J3QgcXVpdGUgdGhlIHNhbWUNCnRoaW5nIGFzICJ1c2VyPXBob25lLCIgYWx0aG91Z2ggdGhleSBk byBzZWVtIHN1cGVyZmljaWFsbHkgc2ltaWxhci4gV2UNCndvdWxkIG5lZWQgdG8gZGVmaW5lIHJ1 bGVzIGFyb3VuZCB0aGlzIHBhcmFtZXRlciB0aGF0IGVmZmVjdGl2ZWx5IHNheSwNCiJpZiB5b3Ug c2VlIHRoaXMgcGFyYW1ldGVyIG9uIGEgVVJJLCB5b3UgYXJlIGZyZWUgdG8gZGlzY2FyZCB0aGUg ZG9tYWluDQphbmQgYWN0IGFzIHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJIiAodGhpcyBpcyB0aGUg bWF0ZXJpYWwgZGlmZmVyZW5jZQ0KZnJvbSAidXNlcj1waG9uZSIpLjxicj4NCiAgPC9saT4NCjwv dWw+DQo8YnI+DQpJIGxpa2UgdGhlIGZpcnN0IG9uZSBiZWNhdXNlIGl0J3MgYWxyZWFkeSBzcGVj aWZpZWQuPGJyPg0KPGJyPg0KL2E8YnI+DQo8L2JvZHk+DQo8L2h0bWw+DQoNCg== --part15516-boundary-518362682-661752583-- From john.elwell@siemens-enterprise.com Fri Jan 29 02:32:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7E33A69CA for ; Fri, 29 Jan 2010 02:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 7u7T2WeDubeQ for ; Fri, 29 Jan 2010 02:32:45 -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 5BEC13A6991 for ; Fri, 29 Jan 2010 02:32:45 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-711593; Fri, 29 Jan 2010 11:33:03 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6207A23F0278; Fri, 29 Jan 2010 11:33:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 29 Jan 2010 11:33:03 +0100 From: "Elwell, John" To: Adam Roach , Spencer Dawkins Date: Fri, 29 Jan 2010 11:33:01 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqgaermRb3VmgufR36YjCy73ISI8QAYmo0Q Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B6210AB.1050309@nostrum.com> In-Reply-To: <4B6210AB.1050309@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 10:32:46 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 28 January 2010 22:33 > To: Spencer Dawkins > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > On 1/28/10 3:39 PM, Spencer Dawkins wrote:=20 >=20 > We're talking about E.164 numbers like we can easily=20 > identify them. My=20 > understanding from Tuesday's call was that people on=20 > the call thought the=20 > only way we could unambiguously know that we had an=20 > E.164 number was if we=20 > had a tel: URI. If people on this list want to=20 > challenge that assertion, this would=20 > be a great time to say so - please push back Real Soon Now.=20 > =09 >=20 >=20 > I believe that's true. A large part of what we've been=20 > arguing over relates directly to questions around who is=20 > responsible for which actions when domains are involved. It=20 > is squarely the domains themselves that cause so much=20 > consternation and confusion in this context, and any=20 > simplifications that arise from limiting the scope to E.164=20 > numbers are predicated _completely_ on the elimination of domains. >=20 > As far as I can tell, we really have two approaches we can consider: >=20 >=20 > * Use tel: URIs. Their lack of domains eliminates=20 > domain-related issues. > =09 > =09 > * Define a new sip: URI parameter that effectively means=20 > "the user portion is an E.164 number that can be evaluated by=20 > anyone in the world regardless of the domain attached to it."=20 > This isn't quite the same thing as "user=3Dphone," although=20 > they do seem superficially similar. We would need to define=20 > rules around this parameter that effectively say, "if you see=20 > this parameter on a URI, you are free to discard the domain=20 > and act as responsible for the URI" (this is the material=20 > difference from "user=3Dphone"). > =09 >=20 >=20 > I like the first one because it's already specified. [JRE]Let's drill down a bit further. I am assuming a REGISTER-based solutio= n, where the REGISTER request contains a single AOR (in To/From) and implic= itly registers a bunch of tel URIs. Does that single AOR need to be a tel U= RI, or could it be a SIP/SIPS URI? If it can be a SIP/SIPS URI, perhaps we = don't need to change REGISTER beyond the sort of changes we already anticip= ated in MARTINI. Secondly, how would the PBX populate From and PAI in outbound requests such= as INVITE when the call originates at a UA having credentials appropriate = for one of the registered tel URIs? Would there be an expectation that the = tel URI be used in this case? Although outside the scope of what we are doi= ng with SIPconnect at present, bear in mind that RFC 4474 cannot be used wi= th a tel: URI. Also a tel: URI-based solution would seem to prevent the PBX= minting its own gruus, which implies the need for the SSP to map local con= tacts to gruus and vice versa, thereby legitimising one of the things that = we know breaks RFC 4474. Is this the way we really want to go? I can see this might be a quick way of getting round the present predicamen= t with needing a fast solution for E.164 numbers, but we really need to und= erstand the limitations we are building into this mechanism. Also, use of tel: URIs is currently fairly low compared with use of E.164-b= ased SIP URIs. I can speak from the point of view of a PBX or a network of = PBXs, and this would require either a change-out from using SIP URIs within= the PBX or network, or a mapping between SIP and TEL URIs at the border. N= ot a particularly attractive scenario. But I would also like to hear the SS= P perspective on this. John From bruno.chatras@orange-ftgroup.com Fri Jan 29 04:35:26 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7F73A6A24 for ; Fri, 29 Jan 2010 04:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 N2TDiPj8oujn for ; Fri, 29 Jan 2010 04:35:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 31CC93A688D for ; Fri, 29 Jan 2010 04:35:25 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 85386248557; Fri, 29 Jan 2010 13:35:45 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6BEE827C037; Fri, 29 Jan 2010 13:35:45 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 13:35:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 13:35:44 +0100 Message-ID: <32348_1264768545_4B62D621_32348_3953_1_9ECCF01B52E7AB408A7EB8535264214101082B15@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistrationfirst Thread-Index: AcqfGG4LHcBDOAo4QAmgvsHFtgT3jwA13UcgABLRTQAAKP+jYA== References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> From: To: , , X-OriginalArrivalTime: 29 Jan 2010 12:35:44.0831 (UTC) FILETIME=[939F1CF0:01CAA0DF] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.29.113925 Subject: Re: [martini] Proposed work split: tackle telephone-numberregistrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 12:35:26 -0000 =20 > -----Message d'origine----- > De : Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Envoy=E9 : jeudi 28 janvier 2010 18:25 > =C0 : CHATRAS Bruno RD-CORE-ISS; dean.willis@softarmor.com;=20 > martini@ietf.org > Objet : RE: [martini] Proposed work split: tackle=20 > telephone-numberregistrationfirst >=20 > Hi Bruno, comments inline... >=20 > > -----Original Message----- > > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > > Behalf Of bruno.chatras@orange-ftgroup.com > > Sent: Thursday, January 28, 2010 5:06 AM > >=20 > > Looking to this proposal, another question comes to my=20 > mind. There is=20 > > something that I don't understand from an Industry viewpoint. > >=20 > > - 3GPP/ETSI have defined a solution that applies to all types of=20 > > identities (E.164 numbers, private numbers and email-style=20 > URI). For=20 > > various reasons this solution is not deemed suitable by the MARTINI=20 > > community. >=20 > Martini was instigated from work we were doing in SIP-Forum,=20 > and in the SIP-Forum at one point we were nearly identical to=20 > the 3gpp/etsi mechanism, but technical objections and issues=20 > were raised, which drove us to go to the IETF. The 50,000ft=20 > view of the issues were that the 3gpp/etsi model "works" as=20 > long as everyone's on the same page - that they all happen to=20 > be provisioned to implement the exact same procedures from=20 > the same version of the specs. They all have to know that=20 > the "normal" procedures of 3261 are not being followed, and=20 > they have to know which procedures are being followed,=20 > without any on-the-wire indication that or what they are.=20=20 > For example, they have to know that the request-URI is or is=20 > not going to be the registered contact (it can be either way,=20 > just based on a provisioned field).=20 >=20 > That's all fine on the SSP-side, because presumably they=20 > control all their own equipment. But on the Enterprise side=20 > it's harder. In particular, while we've seen plenty of IMS=20 > equipment support it, we've seen a very small percentage of=20 > PBX's do so, relatively. =3D=3D>BC: I don't think a PBX needs to be "IMS aware" to accept an inbound= INVITE request with a Request-URI containing either the registered contact= or one of its AoRs. >=20 > Obviously the same will/can be said of any Martini or=20 > SIP-Forum work - all the devices will have to do Martini=20 > (whatever it is) for it to work. There will be an=20 > on-the-wire indication of it, so at least one can know what=20 > the other device does or needs, so that's better, but at the=20 > end of the day as you said the question is whether the=20 > industry will adopt it. In the best case scenario 3GPP,=20 > ETSI, SIP-Forum, and CableLabs will all adopt the Martini=20 > work - possibly as an alternative, or maybe even as the new=20 > way. For example the draft-shaken model is very=20 > close/similar to the current 3gpp model.=20=20 =3D=3D>: That's true. However the draft-shaken is not restricted to E.614 n= umbers as far as I understand. The question I raised was in response to the= proposal to work on an E.164-only solution. >=20 > -hadriel >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From bruno.chatras@orange-ftgroup.com Fri Jan 29 05:39:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C4B3A6A22 for ; Fri, 29 Jan 2010 05:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 s-CdS2nx8Ig8 for ; Fri, 29 Jan 2010 05:39:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id C6FBF3A6A13 for ; Fri, 29 Jan 2010 05:39:28 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id C1EB21B82F8; Fri, 29 Jan 2010 14:39:49 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 74AEE18006E; Fri, 29 Jan 2010 14:39:49 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 14:39: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: Fri, 29 Jan 2010 14:39:48 +0100 Message-ID: <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: AcqgZSY6/iakjN0uQKOcyKhm+a2DWQAghKYA References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> From: To: , , , X-OriginalArrivalTime: 29 Jan 2010 13:39:49.0501 (UTC) FILETIME=[873932D0:01CAA0E8] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.13.111532 Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 13:39:31 -0000 Hi Spencer, I have seen you request on the sip-ops list where you noted that MARTINI is= not getting inputs from other operators (than CableLabs). I'm actually rep= resenting a fixed and mobile operator (France Telecom - Orange) and as you = can guess from my previous posts we support a REGISTER-based solution and b= elieve that a solution restricted to Tel URIs would be of limited interest. /BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > Envoy=E9 : jeudi 28 janvier 2010 22:59 > =C0 : Brian Lindsay; Eric Burger; Dean Willis > Cc : martini@ietf.org > Objet : Re: [martini] Proposed work=20 > split:tackletelephone-numberregistration first >=20 > Hi, Brian, >=20 > Thanks for the quick feedback. I'm mostly asking if I'm=20 > reading where we are going correctly (I GOTTA get the draft=20 > minutes out from that call!). >=20 > This is kind of twisty-little-passages-all-alike/different=20 > (for those of you that remember the "adventure" game in the=20 > early 1980s), but I'm trying to follow the chain. Where I=20 > thought we were, was that we didn't have a coherent story for=20 > how we get a call from outside the service provider, to the=20 > service provider, to the SIP-PBX, and I've heard a bunch of=20 > smart guys talk for a long time on a number of occasions=20 > about how that might work/not work, usually ending with "but=20 > if this was limited to E.164 numbers, a lot of these problems=20 > would go away". >=20 > So I'm trying to laces comments from the call that I remember=20 > together, and see what the resulting tapestry looks like. >=20 > Tell you what. I'll go work on draft minutes and stop typing=20 > e-mail, and we'll see if that works better :D >=20 > Spencer >=20 > ----- Original Message ----- > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Eric Burger"=20 > ; "Dean Willis"=20 > > Cc: > Sent: Thursday, January 28, 2010 3:48 PM > Subject: RE: [martini] Proposed work split:=20 > tackletelephone-numberregistration first >=20 >=20 > Hi Spencer, >=20 > I am not sure if this is going down the path that the=20 > actual register > request uses a Tel: URI. >=20 > If so, I don't see why that needs to be the case. The=20 > REGISTER itself > can still be done per Martini-Shaken with a SIP URI=20 > representing the SIP > PBX. In fact, I am not sure too much has to change with Martini-Shaken > unless you want to enforce use of a Tel URI format for requests sent > towards the SIP PBX. >=20 > Thanks > Brian >=20 >=20 >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Thursday, January 28, 2010 4:39 PM > To: Eric Burger; Dean Willis > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: > tackletelephone-numberregistration first >=20 > OK, this discussion continues to be lovely. Thanks again for listening > to the people you're talking to ("plays well with others" is > under-appreciated, once we get out of primary school, but *I*=20 > appreciate > it!) >=20 > After reading this thread down through Eric's note below, I have a few > requests, as co-chair. >=20 > We're talking about E.164 numbers like we can easily identify them. My > understanding from Tuesday's call was that people on the call thought > the only way we could unambiguously know that we had an E.164=20 > number was > if we had a tel: URI. If people on this list want to challenge that > assertion, this would be a great time to say so - please push=20 > back Real > Soon Now. >=20 > If that's true, we're talking about using Tel: URIs. Dean has asserted > that this would require an update to 3261. I'm not a genius=20 > of 3261, but > some of you guys are - could you point us to what you think=20 > needs to be > updated? >=20 > My quick read turned up this text in Section 4, page 17: >=20 > Registration is another common operation in SIP.=20=20 > Registration is one > way that the biloxi.com server can learn the current=20 > location of Bob. > Upon initialization, and at periodic intervals, Bob's SIP=20 > phone sends > REGISTER messages to a server in the biloxi.com domain=20 > known as a SIP > registrar. The REGISTER messages associate Bob's SIP or SIPS URI > (sip:bob@biloxi.com) with the machine into which he is currently > logged (conveyed as a SIP or SIPS URI in the Contact header field). >=20 > Dean, Is this what you were thinking of? Are there other places that > also need to change? >=20 > As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, > Section 2.1, this change would have to go through SIPCORE,=20 > because it's > an update to 3261. If you know of obvious land mines that we would be > walking into if we propose this change, please say so Real Soon Now. > (One obvious land mine is that DISPATCH isn't meeting in=20 > Anaheim, so the > proposal would have to be DISPATCHed on the mailing list in=20 > order to do > something before IETF 78 - are there OTHERS?) >=20 > Finally, if you believe that embracing tel: URIs is the wrong thing to > do, please say so, Real Soon Now. >=20 > The milestones that we committed to in > http://tools.ietf.org/wg/martini/charters have us adopting a working > group SOLUTION draft in January. We're not late yet, but it's the 28th > of January in my time zone. If we are late, where late is measured in > days, I can live with that, but if we are late, where late is measured > in IETF meeting cycles, that's going to be a problem. >=20 > Thanks, >=20 > Spencer, as co-chair >=20 > ----- Original Message ----- > From: "Eric Burger" > To: "Dean Willis" > Cc: > Sent: Thursday, January 28, 2010 12:32 PM > Subject: Re: [martini] Proposed work split: tackle > telephone-numberregistration first >=20 >=20 > > If you ask me (why can't I stay in retirement?), the E.164 situation > is > > not only a simplification, but just about the only thing that is > sensible > > for MARTINI to work on. > > > > The E.164 situation is a clear, present, industry-is-begging-for-a- > > solution problem. It is so pressing, the industry will tell us (the > > IETF) to get stuffed and do something stupid if we cannot deliver > > something that is not at its core fundamentally broken. > > > > I do not think anyone can have an issue with mechanisms=20 > that translate > a > > string of digits into an AOR that might cross domain boundaries. > This is > > the E.164 problem statement. > > > > If think everyone (with a brain) SHOULD have issues with a mechanism > that > > magically mungs "sip:eburger@neustar.biz" into > "sip:5350@pbx.example.net " > > while at the same time www.neustar.biz is really a neustar.biz > domain. > > That really would be creating a parallel DNS, which, as one of the > major > > DNS operators, would really, really be "less than ideal" and have a > whole > > host of security and integrity issues. > > > > THEREFORE, I would propose that we split this work into two phases: > > Phase 1: Deliver an E.164 solution, preferably in the next few > months, > > so the industry does not ignore the IETF. > > > > Phase 2: Deliver the generic solution in the normal, 3-5 year IETF > > cycle. This generic solution may or may not encompass=20 > E.164 numbers. > As > > Doug Sauder points out, E.164 numbers and their infrastructure are > > different. Thus a different E.164 registration model from=20 > generic SIP > > URI provisioning models would neither be a burden on industry nor > create > > backwards-compatibility issues for the generic solution. > > > > Note that if we do not deliver Phase 1 in a very, very=20 > timely manner, > the > > less-than-idea industry solution just might blow up the possibility > for > > the generic solution, which would be considerably less than ideal. > > > > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > > > >> > >> We seem to have an urgent need for a near-term solution for dealing > with > >> the subset of the MARTINI problem that, loosely defined,=20 > covers the > >> "telephone number" problem. > >> > >> The typical scenario here is SIP trunking, wherein a SIP Service > >> Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's > >> PBX (or PBXes). In this model, the SSP maps a whole bunch=20 > of phone > >> numbers to the PBXes. This mapping is somewhat dynamic,=20 > because the > >> PBXes usually have DHCP addresses, and don't have DNS entries that > point > >> A records at the PBX in any sort of particularly useful way (maybe > >> something like dhcp-10-1-2-3- example.com). > >> > >> So what we need is a way for a PBX, when it reboots (or perhaps > >> periodically) to say to the SSP "Here I Am; You may now send any > calls > >> for my assigned phone numbers to my current Contact." > >> > >> This is indeed a "registration" problem, but it isn't necessarily a > >> "domain registration problem". The only reason domains get mixed > into > >> this scenario at all is that we sometimes encode telephone numbers > as > >> the user parts of SIP URIs, and those SIP URIs have a domain part > >> attached to them. > >> > >> More interestingly, this problem is a tiny subset of the whole > MARTINI > >> dynamic binding problem, and it potentially can be solved=20=20 > much more > >> simply than the general problem. > >> > >> On today's Interim II call, Richard, Adam and I raised the idea of > >> dividing our problem space, and taking on a near-term milestone for > >> delivering a MARTINI solution for registering contacts to a proxy, > where > >> that proxy maps one or more telephone numbers to the contact. > >> > >> We certainly intend to go on and tackle the more general domain- > >> registration problem, but I (and I believe Adam and=20 > Richard) believe > >> that we get a lot out of tackling the telephone-number=20 > subset first. > >> > >> In particular, we believe that this approach solves many of the > domain > >> "responsibility" questions, simplifies the TLS keying/=20 > certification > >> model immensely, eliminates the cognitive overload of=20=20 > using REGISTER > to > >> bind a "domain" to a Contact, "route authentication", and a good > many > >> other open issues that plague our current drafts. > >> > >> > >> Open questions relating to this approach include: > >> > >> 1) Do we deal only with E.164 numbers, or do we need to deal with > >> private-number "phone contexts"? > >> > >> 2) D owe need to explicitly encode the telephone numbers being > >> registered in the REGISTER request (either directly or through some > sort > >> of regexp), or is it adequate to rely on provisioning of=20 > the SSP and > PBX > >> (and any UAs) to statically bind the numbers to the PBX identity, > and > >> then dynamically only register the PBX identity to the=20=20 > PBX contact? > >> > >> 3) Can we "register" with a tel: URI as the "To" value? (this seems > to > >> require extending RFC 3261)? Note that "tel:" can express=20 > both E. 164 > >> numbers and private phone-contexts in one format. > >> > >> 4) What happens with GRUUs? > >> > >> I believe all of these issues are quite tractable, if we accept the > >> fundamental idea of splitting the phone-number problem off from the > more > >> general domain-registration, and recognize the possibility=20 > that the > >> solutions to the two problem may reasonably be quite=20 > different from > each > >> other. > >> > >> So, what do you people think? Is it worth trying to drink the > MARTINI > >> elephant one sip at a time, or are we going to treat the=20=20 > whole thing > >> like a tequila shot and just slam it down? > >> > >> -- > >> Dean > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From spencer@wonderhamster.org Fri Jan 29 05:47:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CCD3A6A51 for ; Fri, 29 Jan 2010 05:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, STOX_REPLY_TYPE=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 C9PGoamCjOMP for ; Fri, 29 Jan 2010 05:47:30 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4E1C03A68CC for ; Fri, 29 Jan 2010 05:47:30 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M09S8-1NvYKu2Wgm-00uKLO; Fri, 29 Jan 2010 08:47:30 -0500 Message-ID: <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> From: "Spencer Dawkins" To: , , , References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> Date: Fri, 29 Jan 2010 07:47:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: V01U2FsdGVkX18MD9Xfv1zWe909AJm+ao5oB1F1BFsOby8r7PO 6NnEBhFCsGvLMzJl9h6/XEKFdlDypXrDY0/wxq4pF3o3FIdhJ6 cISmLSSBNgHMQH1+XS4UFomi5Px8RXvgGukfGJit6A= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 13:47:32 -0000 Hi, Bruno, My apologies for not snapping when I saw your e-mail address - I'm currently chairing three working groups, and things are getting a little blurry (MEDIACTRL *really* needs to finish soon!). Thanks for the input - it's helpful. Spencer ----- Original Message ----- From: To: ; ; ; Cc: Sent: Friday, January 29, 2010 7:39 AM Subject: RE: [martini] Proposed work split:tackletelephone-numberregistration first Hi Spencer, I have seen you request on the sip-ops list where you noted that MARTINI is not getting inputs from other operators (than CableLabs). I'm actually representing a fixed and mobile operator (France Telecom - Orange) and as you can guess from my previous posts we support a REGISTER-based solution and believe that a solution restricted to Tel URIs would be of limited interest. /BC > -----Message d'origine----- > De : martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > Envoyé : jeudi 28 janvier 2010 22:59 > À : Brian Lindsay; Eric Burger; Dean Willis > Cc : martini@ietf.org > Objet : Re: [martini] Proposed work > split:tackletelephone-numberregistration first > > Hi, Brian, > > Thanks for the quick feedback. I'm mostly asking if I'm > reading where we are going correctly (I GOTTA get the draft > minutes out from that call!). > > This is kind of twisty-little-passages-all-alike/different > (for those of you that remember the "adventure" game in the > early 1980s), but I'm trying to follow the chain. Where I > thought we were, was that we didn't have a coherent story for > how we get a call from outside the service provider, to the > service provider, to the SIP-PBX, and I've heard a bunch of > smart guys talk for a long time on a number of occasions > about how that might work/not work, usually ending with "but > if this was limited to E.164 numbers, a lot of these problems > would go away". > > So I'm trying to laces comments from the call that I remember > together, and see what the resulting tapestry looks like. > > Tell you what. I'll go work on draft minutes and stop typing > e-mail, and we'll see if that works better :D > > Spencer > > ----- Original Message ----- > From: "Brian Lindsay" > To: "Spencer Dawkins" ; "Eric Burger" > ; "Dean Willis" > > Cc: > Sent: Thursday, January 28, 2010 3:48 PM > Subject: RE: [martini] Proposed work split: > tackletelephone-numberregistration first > > > Hi Spencer, > > I am not sure if this is going down the path that the > actual register > request uses a Tel: URI. > > If so, I don't see why that needs to be the case. The > REGISTER itself > can still be done per Martini-Shaken with a SIP URI > representing the SIP > PBX. In fact, I am not sure too much has to change with Martini-Shaken > unless you want to enforce use of a Tel URI format for requests sent > towards the SIP PBX. > > Thanks > Brian > > > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > Behalf Of Spencer Dawkins > Sent: Thursday, January 28, 2010 4:39 PM > To: Eric Burger; Dean Willis > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: > tackletelephone-numberregistration first > > OK, this discussion continues to be lovely. Thanks again for listening > to the people you're talking to ("plays well with others" is > under-appreciated, once we get out of primary school, but *I* > appreciate > it!) > > After reading this thread down through Eric's note below, I have a few > requests, as co-chair. > > We're talking about E.164 numbers like we can easily identify them. My > understanding from Tuesday's call was that people on the call thought > the only way we could unambiguously know that we had an E.164 > number was > if we had a tel: URI. If people on this list want to challenge that > assertion, this would be a great time to say so - please push > back Real > Soon Now. > > If that's true, we're talking about using Tel: URIs. Dean has asserted > that this would require an update to 3261. I'm not a genius > of 3261, but > some of you guys are - could you point us to what you think > needs to be > updated? > > My quick read turned up this text in Section 4, page 17: > > Registration is another common operation in SIP. > Registration is one > way that the biloxi.com server can learn the current > location of Bob. > Upon initialization, and at periodic intervals, Bob's SIP > phone sends > REGISTER messages to a server in the biloxi.com domain > known as a SIP > registrar. The REGISTER messages associate Bob's SIP or SIPS URI > (sip:bob@biloxi.com) with the machine into which he is currently > logged (conveyed as a SIP or SIPS URI in the Contact header field). > > Dean, Is this what you were thinking of? Are there other places that > also need to change? > > As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, > Section 2.1, this change would have to go through SIPCORE, > because it's > an update to 3261. If you know of obvious land mines that we would be > walking into if we propose this change, please say so Real Soon Now. > (One obvious land mine is that DISPATCH isn't meeting in > Anaheim, so the > proposal would have to be DISPATCHed on the mailing list in > order to do > something before IETF 78 - are there OTHERS?) > > Finally, if you believe that embracing tel: URIs is the wrong thing to > do, please say so, Real Soon Now. > > The milestones that we committed to in > http://tools.ietf.org/wg/martini/charters have us adopting a working > group SOLUTION draft in January. We're not late yet, but it's the 28th > of January in my time zone. If we are late, where late is measured in > days, I can live with that, but if we are late, where late is measured > in IETF meeting cycles, that's going to be a problem. > > Thanks, > > Spencer, as co-chair > > ----- Original Message ----- > From: "Eric Burger" > To: "Dean Willis" > Cc: > Sent: Thursday, January 28, 2010 12:32 PM > Subject: Re: [martini] Proposed work split: tackle > telephone-numberregistration first > > > > If you ask me (why can't I stay in retirement?), the E.164 situation > is > > not only a simplification, but just about the only thing that is > sensible > > for MARTINI to work on. > > > > The E.164 situation is a clear, present, industry-is-begging-for-a- > > solution problem. It is so pressing, the industry will tell us (the > > IETF) to get stuffed and do something stupid if we cannot deliver > > something that is not at its core fundamentally broken. > > > > I do not think anyone can have an issue with mechanisms > that translate > a > > string of digits into an AOR that might cross domain boundaries. > This is > > the E.164 problem statement. > > > > If think everyone (with a brain) SHOULD have issues with a mechanism > that > > magically mungs "sip:eburger@neustar.biz" into > "sip:5350@pbx.example.net " > > while at the same time www.neustar.biz is really a neustar.biz > domain. > > That really would be creating a parallel DNS, which, as one of the > major > > DNS operators, would really, really be "less than ideal" and have a > whole > > host of security and integrity issues. > > > > THEREFORE, I would propose that we split this work into two phases: > > Phase 1: Deliver an E.164 solution, preferably in the next few > months, > > so the industry does not ignore the IETF. > > > > Phase 2: Deliver the generic solution in the normal, 3-5 year IETF > > cycle. This generic solution may or may not encompass > E.164 numbers. > As > > Doug Sauder points out, E.164 numbers and their infrastructure are > > different. Thus a different E.164 registration model from > generic SIP > > URI provisioning models would neither be a burden on industry nor > create > > backwards-compatibility issues for the generic solution. > > > > Note that if we do not deliver Phase 1 in a very, very > timely manner, > the > > less-than-idea industry solution just might blow up the possibility > for > > the generic solution, which would be considerably less than ideal. > > > > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > > > >> > >> We seem to have an urgent need for a near-term solution for dealing > with > >> the subset of the MARTINI problem that, loosely defined, > covers the > >> "telephone number" problem. > >> > >> The typical scenario here is SIP trunking, wherein a SIP Service > >> Provider (SSP) provides an ISDN-PRI like service over IP to a > customer's > >> PBX (or PBXes). In this model, the SSP maps a whole bunch > of phone > >> numbers to the PBXes. This mapping is somewhat dynamic, > because the > >> PBXes usually have DHCP addresses, and don't have DNS entries that > point > >> A records at the PBX in any sort of particularly useful way (maybe > >> something like dhcp-10-1-2-3- example.com). > >> > >> So what we need is a way for a PBX, when it reboots (or perhaps > >> periodically) to say to the SSP "Here I Am; You may now send any > calls > >> for my assigned phone numbers to my current Contact." > >> > >> This is indeed a "registration" problem, but it isn't necessarily a > >> "domain registration problem". The only reason domains get mixed > into > >> this scenario at all is that we sometimes encode telephone numbers > as > >> the user parts of SIP URIs, and those SIP URIs have a domain part > >> attached to them. > >> > >> More interestingly, this problem is a tiny subset of the whole > MARTINI > >> dynamic binding problem, and it potentially can be solved > much more > >> simply than the general problem. > >> > >> On today's Interim II call, Richard, Adam and I raised the idea of > >> dividing our problem space, and taking on a near-term milestone for > >> delivering a MARTINI solution for registering contacts to a proxy, > where > >> that proxy maps one or more telephone numbers to the contact. > >> > >> We certainly intend to go on and tackle the more general domain- > >> registration problem, but I (and I believe Adam and > Richard) believe > >> that we get a lot out of tackling the telephone-number > subset first. > >> > >> In particular, we believe that this approach solves many of the > domain > >> "responsibility" questions, simplifies the TLS keying/ > certification > >> model immensely, eliminates the cognitive overload of > using REGISTER > to > >> bind a "domain" to a Contact, "route authentication", and a good > many > >> other open issues that plague our current drafts. > >> > >> > >> Open questions relating to this approach include: > >> > >> 1) Do we deal only with E.164 numbers, or do we need to deal with > >> private-number "phone contexts"? > >> > >> 2) D owe need to explicitly encode the telephone numbers being > >> registered in the REGISTER request (either directly or through some > sort > >> of regexp), or is it adequate to rely on provisioning of > the SSP and > PBX > >> (and any UAs) to statically bind the numbers to the PBX identity, > and > >> then dynamically only register the PBX identity to the > PBX contact? > >> > >> 3) Can we "register" with a tel: URI as the "To" value? (this seems > to > >> require extending RFC 3261)? Note that "tel:" can express > both E. 164 > >> numbers and private phone-contexts in one format. > >> > >> 4) What happens with GRUUs? > >> > >> I believe all of these issues are quite tractable, if we accept the > >> fundamental idea of splitting the phone-number problem off from the > more > >> general domain-registration, and recognize the possibility > that the > >> solutions to the two problem may reasonably be quite > different from > each > >> other. > >> > >> So, what do you people think? Is it worth trying to drink the > MARTINI > >> elephant one sip at a time, or are we going to treat the > whole thing > >> like a tequila shot and just slam it down? > >> > >> -- > >> Dean > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From pkyzivat@cisco.com Fri Jan 29 06:15:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1623A6A75 for ; Fri, 29 Jan 2010 06:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nh-Q6i5ALosU for ; Fri, 29 Jan 2010 06:15:23 -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 4F9F43A6A72 for ; Fri, 29 Jan 2010 06:15:23 -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: At8EADN8YkutJV2a/2dsb2JhbAAqwxeXU4I0AQ0PDIFlBI4d X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="82898140" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2010 14:15:44 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0TEFibH015465; Fri, 29 Jan 2010 14:15:44 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:15:44 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:15:44 -0600 Message-ID: <4B62ED8D.9050503@cisco.com> Date: Fri, 29 Jan 2010 09:15:41 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2010 14:15:44.0118 (UTC) FILETIME=[8B79A960:01CAA0ED] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:15:25 -0000 Spencer Dawkins wrote: > OK, this discussion continues to be lovely. Thanks again for listening > to the people you're talking to ("plays well with others" is > under-appreciated, once we get out of primary school, but *I* appreciate > it!) > > After reading this thread down through Eric's note below, I have a few > requests, as co-chair. > > We're talking about E.164 numbers like we can easily identify them. My > understanding from Tuesday's call was that people on the call thought the > only way we could unambiguously know that we had an E.164 number was if we > had a tel: URI. If people on this list want to challenge that assertion, > this would > be a great time to say so - please push back Real Soon Now. I don't know that it is the *only* way, but it is an unambiguous way. Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring that everybody concerned agrees that's what they are. I think if the To of > If that's true, we're talking about using Tel: URIs. Dean has asserted > that this would require an update to 3261. I'm not a genius of 3261, but > some of you guys are - could you point us to what you think needs to be > updated? That would come up *if* the intent is to *explicitly* register a TEL URI. The key issue is from section 10.2: To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. But if the goal is to register using a SIP URI, and cause the "implicit registration" of a number of TEL URIs, its not so clear that we have the same problems with 3261. The more important issue is "constructing" an R-URI from a registered contact address as a part of implicit registration, and ensuring that the resulting URIs are unambiguous at the pbx. As long as the implicitly registered AORs are all TEL URIs, or sip URIs with a TEL user part, then the pbx can know what to expect as R-URIs for incoming requests. And it can know that the URI for a given telephone number will be the same regardless of what SSP it uses. (To ensure that, we would want to specify that the E.164 number was represented in its canonical form, without any of the optional separator characters.) Thanks, Paul > My quick read turned up this text in Section 4, page 17: > > Registration is another common operation in SIP. Registration is one > way that the biloxi.com server can learn the current location of Bob. > Upon initialization, and at periodic intervals, Bob's SIP phone sends > REGISTER messages to a server in the biloxi.com domain known as a SIP > registrar. The REGISTER messages associate Bob's SIP or SIPS URI > (sip:bob@biloxi.com) with the machine into which he is currently > logged (conveyed as a SIP or SIPS URI in the Contact header field). > > Dean, Is this what you were thinking of? Are there other places that > also need to change? > > As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, > Section 2.1, this change would have to go through SIPCORE, because it's > an update to 3261. If you know of obvious land mines that we would be > walking into if we propose this change, please say so Real Soon Now. > (One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the > proposal would have to be DISPATCHed on the mailing list in order to do > something before IETF 78 - are there OTHERS?) > > Finally, if you believe that embracing tel: URIs is the wrong thing to > do, please say so, Real Soon Now. > > The milestones that we committed to in > http://tools.ietf.org/wg/martini/charters have us adopting a working > group SOLUTION draft in January. We're not late yet, but it's the 28th > of January in my time zone. If we are late, where late is measured in > days, I can live with that, but if we are late, where late is measured > in IETF meeting cycles, that's going to be a problem. > > Thanks, > > Spencer, as co-chair > > ----- Original Message ----- From: "Eric Burger" > > To: "Dean Willis" > Cc: > Sent: Thursday, January 28, 2010 12:32 PM > Subject: Re: [martini] Proposed work split: tackle > telephone-numberregistration first > > >> If you ask me (why can't I stay in retirement?), the E.164 situation is >> not only a simplification, but just about the only thing that is >> sensible >> for MARTINI to work on. >> >> The E.164 situation is a clear, present, industry-is-begging-for-a- >> solution problem. It is so pressing, the industry will tell us (the >> IETF) to get stuffed and do something stupid if we cannot deliver >> something that is not at its core fundamentally broken. >> >> I do not think anyone can have an issue with mechanisms that translate a >> string of digits into an AOR that might cross domain boundaries. >> This is >> the E.164 problem statement. >> >> If think everyone (with a brain) SHOULD have issues with a mechanism >> that >> magically mungs "sip:eburger@neustar.biz" into >> "sip:5350@pbx.example.net " >> while at the same time www.neustar.biz is really a neustar.biz domain. >> That really would be creating a parallel DNS, which, as one of the major >> DNS operators, would really, really be "less than ideal" and have a >> whole >> host of security and integrity issues. >> >> THEREFORE, I would propose that we split this work into two phases: >> Phase 1: Deliver an E.164 solution, preferably in the next few months, >> so the industry does not ignore the IETF. >> >> Phase 2: Deliver the generic solution in the normal, 3-5 year IETF >> cycle. This generic solution may or may not encompass E.164 >> numbers. As >> Doug Sauder points out, E.164 numbers and their infrastructure are >> different. Thus a different E.164 registration model from generic SIP >> URI provisioning models would neither be a burden on industry nor create >> backwards-compatibility issues for the generic solution. >> >> Note that if we do not deliver Phase 1 in a very, very timely manner, >> the >> less-than-idea industry solution just might blow up the possibility for >> the generic solution, which would be considerably less than ideal. >> >> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >> >>> >>> We seem to have an urgent need for a near-term solution for dealing >>> with >>> the subset of the MARTINI problem that, loosely defined, covers the >>> "telephone number" problem. >>> >>> The typical scenario here is SIP trunking, wherein a SIP Service >>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>> customer's >>> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >>> numbers to the PBXes. This mapping is somewhat dynamic, because the >>> PBXes usually have DHCP addresses, and don't have DNS entries that >>> point >>> A records at the PBX in any sort of particularly useful way (maybe >>> something like dhcp-10-1-2-3- example.com). >>> >>> So what we need is a way for a PBX, when it reboots (or perhaps >>> periodically) to say to the SSP "Here I Am; You may now send any calls >>> for my assigned phone numbers to my current Contact." >>> >>> This is indeed a "registration" problem, but it isn't necessarily a >>> "domain registration problem". The only reason domains get mixed into >>> this scenario at all is that we sometimes encode telephone numbers as >>> the user parts of SIP URIs, and those SIP URIs have a domain part >>> attached to them. >>> >>> More interestingly, this problem is a tiny subset of the whole MARTINI >>> dynamic binding problem, and it potentially can be solved much more >>> simply than the general problem. >>> >>> On today's Interim II call, Richard, Adam and I raised the idea of >>> dividing our problem space, and taking on a near-term milestone for >>> delivering a MARTINI solution for registering contacts to a proxy, >>> where >>> that proxy maps one or more telephone numbers to the contact. >>> >>> We certainly intend to go on and tackle the more general domain- >>> registration problem, but I (and I believe Adam and Richard) believe >>> that we get a lot out of tackling the telephone-number subset first. >>> >>> In particular, we believe that this approach solves many of the domain >>> "responsibility" questions, simplifies the TLS keying/ certification >>> model immensely, eliminates the cognitive overload of using REGISTER to >>> bind a "domain" to a Contact, "route authentication", and a good many >>> other open issues that plague our current drafts. >>> >>> >>> Open questions relating to this approach include: >>> >>> 1) Do we deal only with E.164 numbers, or do we need to deal with >>> private-number "phone contexts"? >>> >>> 2) D owe need to explicitly encode the telephone numbers being >>> registered in the REGISTER request (either directly or through some >>> sort >>> of regexp), or is it adequate to rely on provisioning of the SSP and >>> PBX >>> (and any UAs) to statically bind the numbers to the PBX identity, and >>> then dynamically only register the PBX identity to the PBX contact? >>> >>> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >>> require extending RFC 3261)? Note that "tel:" can express both E. 164 >>> numbers and private phone-contexts in one format. >>> >>> 4) What happens with GRUUs? >>> >>> I believe all of these issues are quite tractable, if we accept the >>> fundamental idea of splitting the phone-number problem off from the >>> more >>> general domain-registration, and recognize the possibility that the >>> solutions to the two problem may reasonably be quite different from >>> each >>> other. >>> >>> So, what do you people think? Is it worth trying to drink the MARTINI >>> elephant one sip at a time, or are we going to treat the whole thing >>> like a tequila shot and just slam it down? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Fri Jan 29 06:35:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2583A67D3 for ; Fri, 29 Jan 2010 06:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_45=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 p+VbPYLqNA35 for ; Fri, 29 Jan 2010 06:35:58 -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 2D4B03A63D3 for ; Fri, 29 Jan 2010 06:35:58 -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: ApoEAKeAYkutJV2d/2dsb2JhbADDeZdUgjSCDgQ X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="82901137" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 29 Jan 2010 14:36:04 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0TEZvVY016401; Fri, 29 Jan 2010 14:35:57 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:35:57 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:35:56 -0600 Message-ID: <4B62F250.9080207@cisco.com> Date: Fri, 29 Jan 2010 09:36:00 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B6210AB.1050309@nostrum.com> In-Reply-To: <4B6210AB.1050309@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2010 14:35:56.0820 (UTC) FILETIME=[5E4D4D40:01CAA0F0] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:35:59 -0000 I've been thinking about using TEL URIs for a long time. A key distinction to me is that in addition to not specifying a domain, they also don't specify a protocol. So when a sip request is received with a tel: R-URI the recipient is free to switch to some other protocol that is available to it that can reach that number. OTOH, if a request contains a SIP URI, even with user=phone, if the recipient isn't responsible for the domain, then it must route using SIP, and this will continue until it reaches the target domain. (Once there, it could retarget and switch to another protocol, but that is policy of the recipient.) That can be a *feature*. For instance I may have an E.164 number as my AOR so that I am reachable via other protocols. But when the call is sip e2e I get more features, such as extra media, etc. In some cases I may had out TEL uris in order to be maximally reachable. In other cases I may hand out sip URIs with user=phone for use when I want to ensure that the resulting session is sip e2e. And I may had out sips URIs when I want to ensure a "secure" session e2e. That is a reason why it is wrong to use user=phone as an excuse to ignore the domain part of a URI. If we see a need to use SIP URIs but want the option to ignore the domain part, then I agree with what Adam says below - that we need a different parameter. But I'm not yet convinced that would be useful or wise. Thanks, Paul Adam Roach wrote: > On 1/28/10 3:39 PM, Spencer Dawkins wrote: >> We're talking about E.164 numbers like we can easily identify them. My >> understanding from Tuesday's call was that people on the call thought the >> only way we could unambiguously know that we had an E.164 number was >> if we >> had a tel: URI. If people on this list want to challenge that >> assertion, this would >> be a great time to say so - please push back Real Soon Now. > > I believe that's true. A large part of what we've been arguing over > relates directly to questions around who is responsible for which > actions when domains are involved. It is squarely the domains themselves > that cause so much consternation and confusion in this context, and any > simplifications that arise from limiting the scope to E.164 numbers are > predicated _completely_ on the elimination of domains. > > As far as I can tell, we really have two approaches we can consider: > > * Use tel: URIs. Their lack of domains eliminates domain-related issues. > > * Define a new sip: URI parameter that effectively means "the user > portion is an E.164 number that can be evaluated by anyone in the > world regardless of the domain attached to it." This isn't quite > the same thing as "user=phone," although they do seem > superficially similar. We would need to define rules around this > parameter that effectively say, "if you see this parameter on a > URI, you are free to discard the domain and act as responsible for > the URI" (this is the material difference from "user=phone"). > > > I like the first one because it's already specified. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Fri Jan 29 06:39:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ADA93A67D3 for ; Fri, 29 Jan 2010 06:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUIq72dPAJpT for ; Fri, 29 Jan 2010 06:39:29 -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 801513A63D3 for ; Fri, 29 Jan 2010 06:39:29 -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: At8EAEuCYkurR7Ht/2dsb2JhbAAqw0uXVII0AQ0PDIFlBI4d X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="293743276" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2010 14:39:51 +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 o0TEdpCL018634; Fri, 29 Jan 2010 14:39:51 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:39:51 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:39:51 -0600 Message-ID: <4B62F33A.5060405@cisco.com> Date: Fri, 29 Jan 2010 09:39:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2010 14:39:51.0086 (UTC) FILETIME=[E9EF74E0:01CAA0F0] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:39:31 -0000 (I sent this out with an incomplete thought I meant to delete. Here is revised version.) Spencer Dawkins wrote: > OK, this discussion continues to be lovely. Thanks again for listening > to the people you're talking to ("plays well with others" is > under-appreciated, once we get out of primary school, but *I* appreciate > it!) > > After reading this thread down through Eric's note below, I have a few > requests, as co-chair. > > We're talking about E.164 numbers like we can easily identify them. My > understanding from Tuesday's call was that people on the call thought the > only way we could unambiguously know that we had an E.164 number was if we > had a tel: URI. If people on this list want to challenge that assertion, > this would > be a great time to say so - please push back Real Soon Now. I don't know that it is the *only* way, but it is an unambiguous way. Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring that everybody concerned agrees that's what they are. > If that's true, we're talking about using Tel: URIs. Dean has asserted > that this would require an update to 3261. I'm not a genius of 3261, but > some of you guys are - could you point us to what you think needs to be > updated? That would come up *if* the intent is to *explicitly* register a TEL URI. The key issue is from section 10.2: To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. But if the goal is to register using a SIP URI, and cause the "implicit registration" of a number of TEL URIs, its not so clear that we have the same problems with 3261. The more important issue is "constructing" an R-URI from a registered contact address as a part of implicit registration, and ensuring that the resulting URIs are unambiguous at the pbx. As long as the implicitly registered AORs are all TEL URIs, or sip URIs with a TEL user part, then the pbx can know what to expect as R-URIs for incoming requests. And it can know that the URI for a given telephone number will be the same regardless of what SSP it uses. (To ensure that, we would want to specify that the E.164 number was represented in its canonical form, without any of the optional separator characters.) Thanks, Paul > My quick read turned up this text in Section 4, page 17: > > Registration is another common operation in SIP. Registration is one > way that the biloxi.com server can learn the current location of Bob. > Upon initialization, and at periodic intervals, Bob's SIP phone sends > REGISTER messages to a server in the biloxi.com domain known as a SIP > registrar. The REGISTER messages associate Bob's SIP or SIPS URI > (sip:bob@biloxi.com) with the machine into which he is currently > logged (conveyed as a SIP or SIPS URI in the Contact header field). > > Dean, Is this what you were thinking of? Are there other places that > also need to change? > > As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, > Section 2.1, this change would have to go through SIPCORE, because it's > an update to 3261. If you know of obvious land mines that we would be > walking into if we propose this change, please say so Real Soon Now. > (One obvious land mine is that DISPATCH isn't meeting in Anaheim, so the > proposal would have to be DISPATCHed on the mailing list in order to do > something before IETF 78 - are there OTHERS?) > > Finally, if you believe that embracing tel: URIs is the wrong thing to > do, please say so, Real Soon Now. > > The milestones that we committed to in > http://tools.ietf.org/wg/martini/charters have us adopting a working > group SOLUTION draft in January. We're not late yet, but it's the 28th > of January in my time zone. If we are late, where late is measured in > days, I can live with that, but if we are late, where late is measured > in IETF meeting cycles, that's going to be a problem. > > Thanks, > > Spencer, as co-chair > > ----- Original Message ----- From: "Eric Burger" > > To: "Dean Willis" > Cc: > Sent: Thursday, January 28, 2010 12:32 PM > Subject: Re: [martini] Proposed work split: tackle > telephone-numberregistration first > > >> If you ask me (why can't I stay in retirement?), the E.164 situation is >> not only a simplification, but just about the only thing that is >> sensible >> for MARTINI to work on. >> >> The E.164 situation is a clear, present, industry-is-begging-for-a- >> solution problem. It is so pressing, the industry will tell us (the >> IETF) to get stuffed and do something stupid if we cannot deliver >> something that is not at its core fundamentally broken. >> >> I do not think anyone can have an issue with mechanisms that translate a >> string of digits into an AOR that might cross domain boundaries. >> This is >> the E.164 problem statement. >> >> If think everyone (with a brain) SHOULD have issues with a mechanism >> that >> magically mungs "sip:eburger@neustar.biz" into >> "sip:5350@pbx.example.net " >> while at the same time www.neustar.biz is really a neustar.biz domain. >> That really would be creating a parallel DNS, which, as one of the major >> DNS operators, would really, really be "less than ideal" and have a >> whole >> host of security and integrity issues. >> >> THEREFORE, I would propose that we split this work into two phases: >> Phase 1: Deliver an E.164 solution, preferably in the next few months, >> so the industry does not ignore the IETF. >> >> Phase 2: Deliver the generic solution in the normal, 3-5 year IETF >> cycle. This generic solution may or may not encompass E.164 >> numbers. As >> Doug Sauder points out, E.164 numbers and their infrastructure are >> different. Thus a different E.164 registration model from generic SIP >> URI provisioning models would neither be a burden on industry nor create >> backwards-compatibility issues for the generic solution. >> >> Note that if we do not deliver Phase 1 in a very, very timely manner, >> the >> less-than-idea industry solution just might blow up the possibility for >> the generic solution, which would be considerably less than ideal. >> >> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >> >>> >>> We seem to have an urgent need for a near-term solution for dealing >>> with >>> the subset of the MARTINI problem that, loosely defined, covers the >>> "telephone number" problem. >>> >>> The typical scenario here is SIP trunking, wherein a SIP Service >>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>> customer's >>> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >>> numbers to the PBXes. This mapping is somewhat dynamic, because the >>> PBXes usually have DHCP addresses, and don't have DNS entries that >>> point >>> A records at the PBX in any sort of particularly useful way (maybe >>> something like dhcp-10-1-2-3- example.com). >>> >>> So what we need is a way for a PBX, when it reboots (or perhaps >>> periodically) to say to the SSP "Here I Am; You may now send any calls >>> for my assigned phone numbers to my current Contact." >>> >>> This is indeed a "registration" problem, but it isn't necessarily a >>> "domain registration problem". The only reason domains get mixed into >>> this scenario at all is that we sometimes encode telephone numbers as >>> the user parts of SIP URIs, and those SIP URIs have a domain part >>> attached to them. >>> >>> More interestingly, this problem is a tiny subset of the whole MARTINI >>> dynamic binding problem, and it potentially can be solved much more >>> simply than the general problem. >>> >>> On today's Interim II call, Richard, Adam and I raised the idea of >>> dividing our problem space, and taking on a near-term milestone for >>> delivering a MARTINI solution for registering contacts to a proxy, >>> where >>> that proxy maps one or more telephone numbers to the contact. >>> >>> We certainly intend to go on and tackle the more general domain- >>> registration problem, but I (and I believe Adam and Richard) believe >>> that we get a lot out of tackling the telephone-number subset first. >>> >>> In particular, we believe that this approach solves many of the domain >>> "responsibility" questions, simplifies the TLS keying/ certification >>> model immensely, eliminates the cognitive overload of using REGISTER to >>> bind a "domain" to a Contact, "route authentication", and a good many >>> other open issues that plague our current drafts. >>> >>> >>> Open questions relating to this approach include: >>> >>> 1) Do we deal only with E.164 numbers, or do we need to deal with >>> private-number "phone contexts"? >>> >>> 2) D owe need to explicitly encode the telephone numbers being >>> registered in the REGISTER request (either directly or through some >>> sort >>> of regexp), or is it adequate to rely on provisioning of the SSP and >>> PBX >>> (and any UAs) to statically bind the numbers to the PBX identity, and >>> then dynamically only register the PBX identity to the PBX contact? >>> >>> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >>> require extending RFC 3261)? Note that "tel:" can express both E. 164 >>> numbers and private phone-contexts in one format. >>> >>> 4) What happens with GRUUs? >>> >>> I believe all of these issues are quite tractable, if we accept the >>> fundamental idea of splitting the phone-number problem off from the >>> more >>> general domain-registration, and recognize the possibility that the >>> solutions to the two problem may reasonably be quite different from >>> each >>> other. >>> >>> So, what do you people think? Is it worth trying to drink the MARTINI >>> elephant one sip at a time, or are we going to treat the whole thing >>> like a tequila shot and just slam it down? >>> >>> -- >>> Dean >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From eburger@standardstrack.com Fri Jan 29 06:40:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5A83A63D3 for ; Fri, 29 Jan 2010 06:40:28 -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 JczlYt7rMBHv for ; Fri, 29 Jan 2010 06:40:26 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 7241F3A682A for ; Fri, 29 Jan 2010 06:40:26 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.178]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nas1d-0005ef-M9; Fri, 29 Jan 2010 06:40:46 -0800 From: Eric Burger To: bruno.chatras@orange-ftgroup.com In-Reply-To: <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> X-Priority: 3 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 09:40:43 -0500 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: Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:40:28 -0000 On the one hand, I agree we have to work on a general mechanism to =20 enable the SP to provision IP PBXen as well as an efficient way for IP =20= PBXen to register endpoints to an SP. On the other hand, are you willing to wait 3-5 years for the general =20 mechanism? More especially so given the industry today is 99.9% E.164 =20= numbers and needs a solution last year? This is a serious question: if =20= service providers are saying, "This is going to be important, but we =20 really do not need a solution in 3-5 years," then that informs our =20 work: we can relax and engineer the perfect solution. However, almost =20= all of the service providers I speak with say, "A solution to this =20 problem is already a year late. If we do not see something soon [2-3 =20= months] we are going to codify and deploy the (admittedly broken) =20 REGISTER method that we are already using, with or without the IETF. =20 It would be nice if we could have a not-so-broken mechanism, but the =20 market has lost its patience." Again, doing the E.164-only solution today does not mean we ignore the =20= long-term problem. Does this work for you? On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: > Hi, Bruno, > > My apologies for not snapping when I saw your e-mail address - I'm =20 > currently chairing three working groups, and things are getting a =20 > little blurry (MEDIACTRL *really* needs to finish soon!). > > Thanks for the input - it's helpful. > > Spencer > > ----- Original Message ----- From: > To: ; ; = >; > Cc: > Sent: Friday, January 29, 2010 7:39 AM > Subject: RE: [martini] Proposed work split:tackletelephone-=20 > numberregistration first > > > Hi Spencer, > > I have seen you request on the sip-ops list where you noted that =20 > MARTINI is not getting inputs from other operators (than CableLabs). =20= > I'm actually representing a fixed and mobile operator (France =20 > Telecom - Orange) and as you can guess from my previous posts we =20 > support a REGISTER-based solution and believe that a solution =20 > restricted to Tel URIs would be of limited interest. > > /BC > > > >> -----Message d'origine----- >> De : martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins >> Envoy=E9 : jeudi 28 janvier 2010 22:59 >> =C0 : Brian Lindsay; Eric Burger; Dean Willis >> Cc : martini@ietf.org >> Objet : Re: [martini] Proposed work >> split:tackletelephone-numberregistration first >> >> Hi, Brian, >> >> Thanks for the quick feedback. I'm mostly asking if I'm >> reading where we are going correctly (I GOTTA get the draft >> minutes out from that call!). >> >> This is kind of twisty-little-passages-all-alike/different >> (for those of you that remember the "adventure" game in the >> early 1980s), but I'm trying to follow the chain. Where I >> thought we were, was that we didn't have a coherent story for >> how we get a call from outside the service provider, to the >> service provider, to the SIP-PBX, and I've heard a bunch of >> smart guys talk for a long time on a number of occasions >> about how that might work/not work, usually ending with "but >> if this was limited to E.164 numbers, a lot of these problems >> would go away". >> >> So I'm trying to laces comments from the call that I remember >> together, and see what the resulting tapestry looks like. >> >> Tell you what. I'll go work on draft minutes and stop typing >> e-mail, and we'll see if that works better :D >> >> Spencer >> >> ----- Original Message ----- >> From: "Brian Lindsay" >> To: "Spencer Dawkins" ; "Eric Burger" >> ; "Dean Willis" >> >> Cc: >> Sent: Thursday, January 28, 2010 3:48 PM >> Subject: RE: [martini] Proposed work split: >> tackletelephone-numberregistration first >> >> >> Hi Spencer, >> >> I am not sure if this is going down the path that the >> actual register >> request uses a Tel: URI. >> >> If so, I don't see why that needs to be the case. The >> REGISTER itself >> can still be done per Martini-Shaken with a SIP URI >> representing the SIP >> PBX. In fact, I am not sure too much has to change with Martini-=20 >> Shaken >> unless you want to enforce use of a Tel URI format for requests sent >> towards the SIP PBX. >> >> Thanks >> Brian >> >> >> >> -----Original Message----- >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >> Behalf Of Spencer Dawkins >> Sent: Thursday, January 28, 2010 4:39 PM >> To: Eric Burger; Dean Willis >> Cc: martini@ietf.org >> Subject: Re: [martini] Proposed work split: >> tackletelephone-numberregistration first >> >> OK, this discussion continues to be lovely. Thanks again for =20 >> listening >> to the people you're talking to ("plays well with others" is >> under-appreciated, once we get out of primary school, but *I* >> appreciate >> it!) >> >> After reading this thread down through Eric's note below, I have a =20= >> few >> requests, as co-chair. >> >> We're talking about E.164 numbers like we can easily identify them. =20= >> My >> understanding from Tuesday's call was that people on the call thought >> the only way we could unambiguously know that we had an E.164 >> number was >> if we had a tel: URI. If people on this list want to challenge that >> assertion, this would be a great time to say so - please push >> back Real >> Soon Now. >> >> If that's true, we're talking about using Tel: URIs. Dean has =20 >> asserted >> that this would require an update to 3261. I'm not a genius >> of 3261, but >> some of you guys are - could you point us to what you think >> needs to be >> updated? >> >> My quick read turned up this text in Section 4, page 17: >> >> Registration is another common operation in SIP. >> Registration is one >> way that the biloxi.com server can learn the current >> location of Bob. >> Upon initialization, and at periodic intervals, Bob's SIP >> phone sends >> REGISTER messages to a server in the biloxi.com domain >> known as a SIP >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >> (sip:bob@biloxi.com) with the machine into which he is currently >> logged (conveyed as a SIP or SIPS URI in the Contact header field). >> >> Dean, Is this what you were thinking of? Are there other places that >> also need to change? >> >> As I read http://www.ietf.org/id/draft-peterson-rai-=20 >> rfc3427bis-04.txt, >> Section 2.1, this change would have to go through SIPCORE, >> because it's >> an update to 3261. If you know of obvious land mines that we would be >> walking into if we propose this change, please say so Real Soon Now. >> (One obvious land mine is that DISPATCH isn't meeting in >> Anaheim, so the >> proposal would have to be DISPATCHed on the mailing list in >> order to do >> something before IETF 78 - are there OTHERS?) >> >> Finally, if you believe that embracing tel: URIs is the wrong thing =20= >> to >> do, please say so, Real Soon Now. >> >> The milestones that we committed to in >> http://tools.ietf.org/wg/martini/charters have us adopting a working >> group SOLUTION draft in January. We're not late yet, but it's the =20 >> 28th >> of January in my time zone. If we are late, where late is measured in >> days, I can live with that, but if we are late, where late is =20 >> measured >> in IETF meeting cycles, that's going to be a problem. >> >> Thanks, >> >> Spencer, as co-chair >> >> ----- Original Message ----- >> From: "Eric Burger" >> To: "Dean Willis" >> Cc: >> Sent: Thursday, January 28, 2010 12:32 PM >> Subject: Re: [martini] Proposed work split: tackle >> telephone-numberregistration first >> >> >> > If you ask me (why can't I stay in retirement?), the E.164 =20 >> situation >> is >> > not only a simplification, but just about the only thing that is >> sensible >> > for MARTINI to work on. >> > >> > The E.164 situation is a clear, present, industry-is-begging-for-a- >> > solution problem. It is so pressing, the industry will tell us =20 >> (the >> > IETF) to get stuffed and do something stupid if we cannot deliver >> > something that is not at its core fundamentally broken. >> > >> > I do not think anyone can have an issue with mechanisms >> that translate >> a >> > string of digits into an AOR that might cross domain boundaries. >> This is >> > the E.164 problem statement. >> > >> > If think everyone (with a brain) SHOULD have issues with a =20 >> mechanism >> that >> > magically mungs "sip:eburger@neustar.biz" into >> "sip:5350@pbx.example.net " >> > while at the same time www.neustar.biz is really a neustar.biz >> domain. >> > That really would be creating a parallel DNS, which, as one of the >> major >> > DNS operators, would really, really be "less than ideal" and =20 >> have a >> whole >> > host of security and integrity issues. >> > >> > THEREFORE, I would propose that we split this work into two phases: >> > Phase 1: Deliver an E.164 solution, preferably in the next few >> months, >> > so the industry does not ignore the IETF. >> > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year =20 >> IETF >> > cycle. This generic solution may or may not encompass >> E.164 numbers. >> As >> > Doug Sauder points out, E.164 numbers and their infrastructure are >> > different. Thus a different E.164 registration model from >> generic SIP >> > URI provisioning models would neither be a burden on industry nor >> create >> > backwards-compatibility issues for the generic solution. >> > >> > Note that if we do not deliver Phase 1 in a very, very >> timely manner, >> the >> > less-than-idea industry solution just might blow up the =20 >> possibility >> for >> > the generic solution, which would be considerably less than ideal. >> > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >> > >> >> >> >> We seem to have an urgent need for a near-term solution for =20 >> dealing >> with >> >> the subset of the MARTINI problem that, loosely defined, >> covers the >> >> "telephone number" problem. >> >> >> >> The typical scenario here is SIP trunking, wherein a SIP Service >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a >> customer's >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch >> of phone >> >> numbers to the PBXes. This mapping is somewhat dynamic, >> because the >> >> PBXes usually have DHCP addresses, and don't have DNS entries =20 >> that >> point >> >> A records at the PBX in any sort of particularly useful way =20 >> (maybe >> >> something like dhcp-10-1-2-3- example.com). >> >> >> >> So what we need is a way for a PBX, when it reboots (or perhaps >> >> periodically) to say to the SSP "Here I Am; You may now send any >> calls >> >> for my assigned phone numbers to my current Contact." >> >> >> >> This is indeed a "registration" problem, but it isn't =20 >> necessarily a >> >> "domain registration problem". The only reason domains get mixed >> into >> >> this scenario at all is that we sometimes encode telephone =20 >> numbers >> as >> >> the user parts of SIP URIs, and those SIP URIs have a domain part >> >> attached to them. >> >> >> >> More interestingly, this problem is a tiny subset of the whole >> MARTINI >> >> dynamic binding problem, and it potentially can be solved >> much more >> >> simply than the general problem. >> >> >> >> On today's Interim II call, Richard, Adam and I raised the idea of >> >> dividing our problem space, and taking on a near-term milestone =20= >> for >> >> delivering a MARTINI solution for registering contacts to a proxy, >> where >> >> that proxy maps one or more telephone numbers to the contact. >> >> >> >> We certainly intend to go on and tackle the more general domain- >> >> registration problem, but I (and I believe Adam and >> Richard) believe >> >> that we get a lot out of tackling the telephone-number >> subset first. >> >> >> >> In particular, we believe that this approach solves many of the >> domain >> >> "responsibility" questions, simplifies the TLS keying/ >> certification >> >> model immensely, eliminates the cognitive overload of >> using REGISTER >> to >> >> bind a "domain" to a Contact, "route authentication", and a good >> many >> >> other open issues that plague our current drafts. >> >> >> >> >> >> Open questions relating to this approach include: >> >> >> >> 1) Do we deal only with E.164 numbers, or do we need to deal with >> >> private-number "phone contexts"? >> >> >> >> 2) D owe need to explicitly encode the telephone numbers being >> >> registered in the REGISTER request (either directly or through =20 >> some >> sort >> >> of regexp), or is it adequate to rely on provisioning of >> the SSP and >> PBX >> >> (and any UAs) to statically bind the numbers to the PBX identity, >> and >> >> then dynamically only register the PBX identity to the >> PBX contact? >> >> >> >> 3) Can we "register" with a tel: URI as the "To" value? (this =20 >> seems >> to >> >> require extending RFC 3261)? Note that "tel:" can express >> both E. 164 >> >> numbers and private phone-contexts in one format. >> >> >> >> 4) What happens with GRUUs? >> >> >> >> I believe all of these issues are quite tractable, if we accept =20= >> the >> >> fundamental idea of splitting the phone-number problem off from =20= >> the >> more >> >> general domain-registration, and recognize the possibility >> that the >> >> solutions to the two problem may reasonably be quite >> different from >> each >> >> other. >> >> >> >> So, what do you people think? Is it worth trying to drink the >> MARTINI >> >> elephant one sip at a time, or are we going to treat the >> whole thing >> >> like a tequila shot and just slam it down? >> >> >> >> -- >> >> Dean >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> martini mailing list >> >> martini@ietf.org >> >> https://www.ietf.org/mailman/listinfo/martini >> > >> > _______________________________________________ >> > martini mailing list >> > martini@ietf.org >> > https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > > ********************************* > This message and any attachments (the "message") are confidential =20 > and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, =20= > changed or falsified. > If you are not the intended addressee of this message, please cancel =20= > it immediately and inform the sender. > ******************************** > From spencer@wonderhamster.org Fri Jan 29 06:40:51 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C20A3A682A for ; Fri, 29 Jan 2010 06:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 pKYoBA1NgIoB for ; Fri, 29 Jan 2010 06:40:50 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 727553A67F5 for ; Fri, 29 Jan 2010 06:40:50 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M7qga-1Nwe4x3L6W-00vZEp; Fri, 29 Jan 2010 09:41:12 -0500 Message-ID: From: "Spencer Dawkins" To: "Paul Kyzivat" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B62ED8D.9050503@cisco.com> Date: Fri, 29 Jan 2010 08:40:58 -0600 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/VdZr678Oi7fhv6nAa1sjQ1KpNF9FatNUaRhx kKw81P00SDPtQFwe5eshRSJJO7M4yUfevhBeP6szwD0Rpsp4qI jjyzPr5rJpzyaf++srxGYEoM6XiHPlMkMDdn/0KwcM= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:40:51 -0000 Hi, Paul, A question, and a thank-you... >> We're talking about E.164 numbers like we can easily identify them. My >> understanding from Tuesday's call was that people on the call thought the >> only way we could unambiguously know that we had an E.164 number was if >> we >> had a tel: URI. If people on this list want to challenge that assertion, >> this would >> be a great time to say so - please push back Real Soon Now. > > I don't know that it is the *only* way, but it is an unambiguous way. > > Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring > that everybody concerned agrees that's what they are. I think if the To of I'm guessing that your phone rang about here, because the sentence just stopped. I think I know where you were headed, but wanted to make sure that I understood what you were thinking, because I appreciate you spending the time to be helpful here! Did you need to type a little more? >> If that's true, we're talking about using Tel: URIs. Dean has asserted >> that this would require an update to 3261. I'm not a genius of 3261, but >> some of you guys are - could you point us to what you think needs to be >> updated? > > That would come up *if* the intent is to *explicitly* register a TEL URI. > The key issue is from section 10.2: > > To: The To header field contains the address of record whose > registration is to be created, queried, or modified. The To > header field and the Request-URI field typically differ, as > the former contains a user name. This address-of-record MUST > be a SIP URI or SIPS URI. > > But if the goal is to register using a SIP URI, and cause the "implicit > registration" of a number of TEL URIs, its not so clear that we have the > same problems with 3261. > > The more important issue is "constructing" an R-URI from a registered > contact address as a part of implicit registration, and ensuring that the > resulting URIs are unambiguous at the pbx. As long as the implicitly > registered AORs are all TEL URIs, or sip URIs with a TEL user part, then > the pbx can know what to expect as R-URIs for incoming requests. And it > can know that the URI for a given telephone number will be the same > regardless of what SSP it uses. > > (To ensure that, we would want to specify that the E.164 number was > represented in its canonical form, without any of the optional separator > characters.) Yeah, I wondered if we were all talking about the same thing, when I was typing my note. I like your answer ("don't need to revise RFC 3261") better than the other answer. :-) Do other people think we're talking about what Paul is talking about? Thanks, Spencer From spencer@wonderhamster.org Fri Jan 29 06:44:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FC33A697A for ; Fri, 29 Jan 2010 06:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 ZOhILOLOxyio for ; Fri, 29 Jan 2010 06:44:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id F17543A686E for ; Fri, 29 Jan 2010 06:44:09 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MF5NL-1NYMBx0nd5-00GO72; Fri, 29 Jan 2010 09:44:24 -0500 Message-ID: <8EDD587CF77E4B3CB31EB8807C87895E@china.huawei.com> From: "Spencer Dawkins" To: "Paul Kyzivat" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B62F33A.5060405@cisco.com> Date: Fri, 29 Jan 2010 08:44:13 -0600 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: V01U2FsdGVkX18AzG/lOfRXPPKQfk+XNCngO+YbfR+CYWZJUg0 d97vrYnVbNR9KAQaOPdjXkO+Vl3ptza5jrSdLkU+tJo3lBt0Ez vilgiJfNjX9+63SV9+lQitY0YHy9BivJ0GeGvs6bNs= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:44:11 -0000 Hi, Paul, Ah - I was guessing that you'd moved the same topic lower in the note. Thanks for clueing me in for certain! Spencer > (I sent this out with an incomplete thought I meant to delete. Here is > revised version.) > > Spencer Dawkins wrote: >> OK, this discussion continues to be lovely. Thanks again for listening to >> the people you're talking to ("plays well with others" is >> under-appreciated, once we get out of primary school, but *I* appreciate >> it!) >> >> After reading this thread down through Eric's note below, I have a few >> requests, as co-chair. >> >> We're talking about E.164 numbers like we can easily identify them. My >> understanding from Tuesday's call was that people on the call thought the >> only way we could unambiguously know that we had an E.164 number was if >> we >> had a tel: URI. If people on this list want to challenge that assertion, >> this would >> be a great time to say so - please push back Real Soon Now. > > I don't know that it is the *only* way, but it is an unambiguous way. > > Of course sip URIs *can* contain E.164 numbers. The trick is in ensuring > that everybody concerned agrees that's what they are. > >> If that's true, we're talking about using Tel: URIs. Dean has asserted >> that this would require an update to 3261. I'm not a genius of 3261, but >> some of you guys are - could you point us to what you think needs to be >> updated? > > That would come up *if* the intent is to *explicitly* register a TEL > URI. The key issue is from section 10.2: > > To: The To header field contains the address of record whose > registration is to be created, queried, or modified. The To > header field and the Request-URI field typically differ, as > the former contains a user name. This address-of-record MUST > be a SIP URI or SIPS URI. > > But if the goal is to register using a SIP URI, and cause the "implicit > registration" of a number of TEL URIs, its not so clear that we have the > same problems with 3261. > > The more important issue is "constructing" an R-URI from a registered > contact address as a part of implicit registration, and ensuring that > the resulting URIs are unambiguous at the pbx. As long as the implicitly > registered AORs are all TEL URIs, or sip URIs with a TEL user part, then > the pbx can know what to expect as R-URIs for incoming requests. And it > can know that the URI for a given telephone number will be the same > regardless of what SSP it uses. > > (To ensure that, we would want to specify that the E.164 number was > represented in its canonical form, without any of the optional separator > characters.) > > Thanks, > Paul > >> My quick read turned up this text in Section 4, page 17: >> >> Registration is another common operation in SIP. Registration is one >> way that the biloxi.com server can learn the current location of Bob. >> Upon initialization, and at periodic intervals, Bob's SIP phone sends >> REGISTER messages to a server in the biloxi.com domain known as a SIP >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >> (sip:bob@biloxi.com) with the machine into which he is currently >> logged (conveyed as a SIP or SIPS URI in the Contact header field). >> >> Dean, Is this what you were thinking of? Are there other places that also >> need to change? >> >> As I read http://www.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt, >> Section 2.1, this change would have to go through SIPCORE, because it's >> an update to 3261. If you know of obvious land mines that we would be >> walking into if we propose this change, please say so Real Soon Now. (One >> obvious land mine is that DISPATCH isn't meeting in Anaheim, so the >> proposal would have to be DISPATCHed on the mailing list in order to do >> something before IETF 78 - are there OTHERS?) >> >> Finally, if you believe that embracing tel: URIs is the wrong thing to >> do, please say so, Real Soon Now. >> >> The milestones that we committed to in >> http://tools.ietf.org/wg/martini/charters have us adopting a working >> group SOLUTION draft in January. We're not late yet, but it's the 28th of >> January in my time zone. If we are late, where late is measured in days, >> I can live with that, but if we are late, where late is measured in IETF >> meeting cycles, that's going to be a problem. >> >> Thanks, >> >> Spencer, as co-chair >> >> ----- Original Message ----- From: "Eric Burger" >> >> To: "Dean Willis" >> Cc: >> Sent: Thursday, January 28, 2010 12:32 PM >> Subject: Re: [martini] Proposed work split: tackle >> telephone-numberregistration first >> >> >>> If you ask me (why can't I stay in retirement?), the E.164 situation is >>> not only a simplification, but just about the only thing that is >>> sensible >>> for MARTINI to work on. >>> >>> The E.164 situation is a clear, present, industry-is-begging-for-a- >>> solution problem. It is so pressing, the industry will tell us (the >>> IETF) to get stuffed and do something stupid if we cannot deliver >>> something that is not at its core fundamentally broken. >>> >>> I do not think anyone can have an issue with mechanisms that translate >>> a >>> string of digits into an AOR that might cross domain boundaries. This >>> is >>> the E.164 problem statement. >>> >>> If think everyone (with a brain) SHOULD have issues with a mechanism >>> that >>> magically mungs "sip:eburger@neustar.biz" into "sip:5350@pbx.example.net >>> " >>> while at the same time www.neustar.biz is really a neustar.biz domain. >>> That really would be creating a parallel DNS, which, as one of the >>> major >>> DNS operators, would really, really be "less than ideal" and have a >>> whole >>> host of security and integrity issues. >>> >>> THEREFORE, I would propose that we split this work into two phases: >>> Phase 1: Deliver an E.164 solution, preferably in the next few >>> months, >>> so the industry does not ignore the IETF. >>> >>> Phase 2: Deliver the generic solution in the normal, 3-5 year IETF >>> cycle. This generic solution may or may not encompass E.164 numbers. >>> As >>> Doug Sauder points out, E.164 numbers and their infrastructure are >>> different. Thus a different E.164 registration model from generic SIP >>> URI provisioning models would neither be a burden on industry nor >>> create >>> backwards-compatibility issues for the generic solution. >>> >>> Note that if we do not deliver Phase 1 in a very, very timely manner, >>> the >>> less-than-idea industry solution just might blow up the possibility for >>> the generic solution, which would be considerably less than ideal. >>> >>> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >>> >>>> >>>> We seem to have an urgent need for a near-term solution for dealing >>>> with >>>> the subset of the MARTINI problem that, loosely defined, covers the >>>> "telephone number" problem. >>>> >>>> The typical scenario here is SIP trunking, wherein a SIP Service >>>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>>> customer's >>>> PBX (or PBXes). In this model, the SSP maps a whole bunch of phone >>>> numbers to the PBXes. This mapping is somewhat dynamic, because the >>>> PBXes usually have DHCP addresses, and don't have DNS entries that >>>> point >>>> A records at the PBX in any sort of particularly useful way (maybe >>>> something like dhcp-10-1-2-3- example.com). >>>> >>>> So what we need is a way for a PBX, when it reboots (or perhaps >>>> periodically) to say to the SSP "Here I Am; You may now send any calls >>>> for my assigned phone numbers to my current Contact." >>>> >>>> This is indeed a "registration" problem, but it isn't necessarily a >>>> "domain registration problem". The only reason domains get mixed into >>>> this scenario at all is that we sometimes encode telephone numbers as >>>> the user parts of SIP URIs, and those SIP URIs have a domain part >>>> attached to them. >>>> >>>> More interestingly, this problem is a tiny subset of the whole MARTINI >>>> dynamic binding problem, and it potentially can be solved much more >>>> simply than the general problem. >>>> >>>> On today's Interim II call, Richard, Adam and I raised the idea of >>>> dividing our problem space, and taking on a near-term milestone for >>>> delivering a MARTINI solution for registering contacts to a proxy, >>>> where >>>> that proxy maps one or more telephone numbers to the contact. >>>> >>>> We certainly intend to go on and tackle the more general domain- >>>> registration problem, but I (and I believe Adam and Richard) believe >>>> that we get a lot out of tackling the telephone-number subset first. >>>> >>>> In particular, we believe that this approach solves many of the domain >>>> "responsibility" questions, simplifies the TLS keying/ certification >>>> model immensely, eliminates the cognitive overload of using REGISTER >>>> to >>>> bind a "domain" to a Contact, "route authentication", and a good many >>>> other open issues that plague our current drafts. >>>> >>>> >>>> Open questions relating to this approach include: >>>> >>>> 1) Do we deal only with E.164 numbers, or do we need to deal with >>>> private-number "phone contexts"? >>>> >>>> 2) D owe need to explicitly encode the telephone numbers being >>>> registered in the REGISTER request (either directly or through some >>>> sort >>>> of regexp), or is it adequate to rely on provisioning of the SSP and >>>> PBX >>>> (and any UAs) to statically bind the numbers to the PBX identity, and >>>> then dynamically only register the PBX identity to the PBX contact? >>>> >>>> 3) Can we "register" with a tel: URI as the "To" value? (this seems to >>>> require extending RFC 3261)? Note that "tel:" can express both E. 164 >>>> numbers and private phone-contexts in one format. >>>> >>>> 4) What happens with GRUUs? >>>> >>>> I believe all of these issues are quite tractable, if we accept the >>>> fundamental idea of splitting the phone-number problem off from the >>>> more >>>> general domain-registration, and recognize the possibility that the >>>> solutions to the two problem may reasonably be quite different from >>>> each >>>> other. >>>> >>>> So, what do you people think? Is it worth trying to drink the MARTINI >>>> elephant one sip at a time, or are we going to treat the whole thing >>>> like a tequila shot and just slam it down? >>>> >>>> -- >>>> Dean >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From pkyzivat@cisco.com Fri Jan 29 06:44:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A78B28C14B for ; Fri, 29 Jan 2010 06:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEsYO06BIdfM for ; Fri, 29 Jan 2010 06:44:24 -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 41B1428C0D0 for ; Fri, 29 Jan 2010 06:44:24 -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: ApoEAMOCYkurRN+J/2dsb2JhbADEA5dUhEIE X-IronPort-AV: E=Sophos;i="4.49,368,1262563200"; d="scan'208";a="80909164" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2010 14:44:45 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0TEijlN000681; Fri, 29 Jan 2010 14:44:45 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:44:45 -0600 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 08:44:45 -0600 Message-ID: <4B62F45D.1010707@cisco.com> Date: Fri, 29 Jan 2010 09:44:45 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> <4B621432.8040901@nostrum.com> In-Reply-To: <4B621432.8040901@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2010 14:44:45.0174 (UTC) FILETIME=[9939B960:01CAA0F1] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 14:44:25 -0000 Adam Roach wrote: > On 1/28/10 4:05 AM, bruno.chatras@orange-ftgroup.com wrote: >> I'm wondering what could be the motivation of the Industry to adopt >> the E.164-only solution as a near-term solution rather than the >> 3GPP/ETSI solution? This can only happen if the E-164 solution has >> very strong benefits and the 3GPP/ETSI solution has major flaws that >> prevents its implementation. >> > > It does, and we've been discussing them. The 3GPP approach demonstrably > works in walled gardens modeled after the IMS architecture. However, we > are not the Walled Garden Engineering Task Force, so we need to ensure > it works on the Internet at large, including a multitude of > architectures that don't resemble IMS in any useful way. > > As far as I can tell, SIPForum is antsy to get something specified now, > even if its very limited in scope. We determined on the call that many > of the really controversial issues become inapplicable if we're willing > to accept certain restrictions, all of which require scoping the work to > E.164 numbers. I suspect this is true, and that we can knock out a > solution very quickly within this tightly constrained scope. > > And, to be sure, the scope restriction is somewhat tighter than just > "E.164 numbers" -- it actually relates predominantly to the elimination > of domains in the SSP-PBX signaling (which is possibly only if the user > portion is universally unique, as in the case of E.164 numbers). This may be slightly out of scope, but when TEL URIs are used in From, To, Refer-To, etc. then there is no need to deal with issues of whether to use the domain of the pbx, or the ssp, or to translate between them. Thanks, Paul From spencer@wonderhamster.org Fri Jan 29 07:06:05 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBA83A6827 for ; Fri, 29 Jan 2010 07:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_56=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 9gOHaWpD24yC for ; Fri, 29 Jan 2010 07:06:04 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id B74B33A6818 for ; Fri, 29 Jan 2010 07:06:04 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MdJpD-1NIw280PzP-00INDP; Fri, 29 Jan 2010 10:06:26 -0500 Message-ID: From: "Spencer Dawkins" To: "Paul Kyzivat" , "Adam Roach" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr><4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> Date: Fri, 29 Jan 2010 09:06:14 -0600 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: V01U2FsdGVkX18f8KYkErOvOtz7k3ByG+jrePtI9AIpvkL3xa/ nCOXI4LFeqiODh+VzS9ZZRLqB2MwUk482+xjK4oV3ngwqlzjsg xVqHiVrq0LS0nctFmqtT6BuH83Gaj3jUZFZxUfAOTk= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:06:05 -0000 Hi, Paul, Just trying to make sure that I'm in sync here... >> As far as I can tell, SIPForum is antsy to get something specified now, >> even if its very limited in scope. We determined on the call that many of >> the really controversial issues become inapplicable if we're willing to >> accept certain restrictions, all of which require scoping the work to >> E.164 numbers. I suspect this is true, and that we can knock out a >> solution very quickly within this tightly constrained scope. >> >> And, to be sure, the scope restriction is somewhat tighter than just >> "E.164 numbers" -- it actually relates predominantly to the elimination >> of domains in the SSP-PBX signaling (which is possibly only if the user >> portion is universally unique, as in the case of E.164 numbers). > > This may be slightly out of scope, but when TEL URIs are used in From, To, > Refer-To, etc. then there is no need to deal with issues of whether to use > the domain of the pbx, or the ssp, or to translate between them. So, if the TEL URI includes a globally unique number (trying to use RFC 3966 terminology here, please question anything I say that doesn't make sense) that includes the country code and national number as described in RFC 3966, section 5.1.4, that's my understanding as well. Keith was arguing fairly passionately that private numbers ("local numbers" in RFC 3966, section 5.1.5, right?) also needed to be included in anything we do. As I read RFC 3966, private numbers would need to include a phone-context parameter, that could be either a global number or any of its leading digits (but why would we do this and NOT do an E.164 number) or a domain name. If we're back to having a domain name for phone-context, do we have problems similar to the problems that we're talking about with E.164-based SIP URIs? Thanks, Spencer From adam@nostrum.com Fri Jan 29 08:01:50 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A7C28C15E for ; Fri, 29 Jan 2010 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, 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 yT-xI0YjfMS3 for ; Fri, 29 Jan 2010 08:01:49 -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 11EBD28C162 for ; Fri, 29 Jan 2010 08:01:39 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0TG1ssc060859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 10:01:55 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B630672.5040208@nostrum.com> Date: Fri, 29 Jan 2010 10:01:54 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr><4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:01:50 -0000 On 1/29/10 9:06 AM, Spencer Dawkins wrote: > Keith was arguing fairly passionately that private numbers ("local > numbers" in RFC 3966, section 5.1.5, right?) also needed to be > included in anything we do. I think it comes down to whether we need to address private numbering in the short-term quick-n-dirty solution that SIPConnect needs last year, or whether private numbering can wait for the more general solution. Where is the pain point that is driving the urgency? Does it include private numbering plans? /a From pkyzivat@cisco.com Fri Jan 29 08:04:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80F23A6903 for ; Fri, 29 Jan 2010 08:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_56=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 q3p7SBm22-fB for ; Fri, 29 Jan 2010 08:04:11 -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 11F893A67EB for ; Fri, 29 Jan 2010 08:04:11 -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: ApoEAHOWYkutJV2a/2dsb2JhbADDR5dThEIE X-IronPort-AV: E=Sophos;i="4.49,369,1262563200"; d="scan'208";a="474918434" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2010 16:04:33 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0TG4X97003572; Fri, 29 Jan 2010 16:04:33 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 10:04:33 -0600 Received: from [161.44.182.200] ([161.44.182.200]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 10:04:33 -0600 Message-ID: <4B630712.1010902@cisco.com> Date: Fri, 29 Jan 2010 11:04:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Spencer Dawkins References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr><4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jan 2010 16:04:33.0218 (UTC) FILETIME=[BF1F4220:01CAA0FC] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:04:12 -0000 Spencer Dawkins wrote: > Hi, Paul, > > Just trying to make sure that I'm in sync here... > >>> As far as I can tell, SIPForum is antsy to get something specified >>> now, even if its very limited in scope. We determined on the call >>> that many of the really controversial issues become inapplicable if >>> we're willing to accept certain restrictions, all of which require >>> scoping the work to E.164 numbers. I suspect this is true, and that >>> we can knock out a solution very quickly within this tightly >>> constrained scope. >>> >>> And, to be sure, the scope restriction is somewhat tighter than just >>> "E.164 numbers" -- it actually relates predominantly to the >>> elimination of domains in the SSP-PBX signaling (which is possibly >>> only if the user portion is universally unique, as in the case of >>> E.164 numbers). >> >> This may be slightly out of scope, but when TEL URIs are used in From, >> To, Refer-To, etc. then there is no need to deal with issues of >> whether to use the domain of the pbx, or the ssp, or to translate >> between them. > > So, if the TEL URI includes a globally unique number (trying to use RFC > 3966 terminology here, please question anything I say that doesn't make > sense) that includes the country code and national number as described > in RFC 3966, section 5.1.4, that's my understanding as well. > > Keith was arguing fairly passionately that private numbers ("local > numbers" in RFC 3966, section 5.1.5, right?) also needed to be included > in anything we do. As I read RFC 3966, private numbers would need to > include a phone-context parameter, that could be either a global number > or any of its leading digits (but why would we do this and NOT do an > E.164 number) or a domain name. > > If we're back to having a domain name for phone-context, do we have > problems similar to the problems that we're talking about with > E.164-based SIP URIs? Not clear. For the point I was making here that is a non-issue, because any domain in the phone-context is irrelevant to sip routing rules. The tel uri is still globally unique for those private numbers as long as the phone context is included. But the *routing* of such private numbers may be a challenge. Thanks, Paul From adam@nostrum.com Fri Jan 29 08:20:02 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E1C3A6992 for ; Fri, 29 Jan 2010 08:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, 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 hx+AvQloRpsf for ; Fri, 29 Jan 2010 08:20:01 -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 21E6B3A6888 for ; Fri, 29 Jan 2010 08:20:00 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0TGKLi8087771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 10:20:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B630AC5.7070203@nostrum.com> Date: Fri, 29 Jan 2010 10:20:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B6210AB.1050309@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:20:02 -0000 On 1/29/10 4:33 AM, Elwell, John wrote: > Although outside the scope of what we are doing with SIPconnect at present, bear in mind that RFC 4474 cannot be used with a tel: URI. It also doesn't do what people expect it to do when you use E.164-like identifiers in SIP URIs. I can easily make a valid RFC4474 assertion that I own the identity "sip:+441908855608@estacado.net;user=phone". And, from a pure SIP perspective, it would be 100% true. But it's probably a bit surprising. /a From bruno.chatras@orange-ftgroup.com Fri Jan 29 08:27:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B89A3A6919 for ; Fri, 29 Jan 2010 08:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 Nj+7AKxPNT51 for ; Fri, 29 Jan 2010 08:27:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 2BAB73A68B4 for ; Fri, 29 Jan 2010 08:27:41 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 177F013455B; Fri, 29 Jan 2010 17:28:02 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id EE0894C075; Fri, 29 Jan 2010 17:28:01 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 17:28:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 17:28:00 +0100 Message-ID: <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: Acqg8TIEZMc15xyZRHeApEs7WU35dgAA4eAQ References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> From: To: X-OriginalArrivalTime: 29 Jan 2010 16:28:02.0581 (UTC) FILETIME=[072AFC50:01CAA100] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.1.18.71820 Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:27:44 -0000 Of course we do not need a solution in 3-5 years. However I hardly believe = that a generic solution would require 3-5 years if the E.164-only solutions= requires only 2 or 3 months.=20 I also understand that doing the E.164-only solution today does not mean we= ignore the long-term problem. However I still think that an E.164-only sol= ution has almost no value compared to the current 3GPP/ETSI solution, espec= ially if the long-term solution significantly differs from the E.164-only s= olution. I'm not convinced that the issues identified with the 3GPP/ETSI/IM= S solution prevent implementing it even outside the context of the IMS. I'm= aware of a number of PBX on the market than can already accept an inbound = INVITE request with a Request-URI containing either the registered contact = or one of the implictly or explictly registered AoRs.=20 BC > -----Message d'origine----- > De : Eric Burger [mailto:eburger@standardstrack.com]=20 > Envoy=E9 : vendredi 29 janvier 2010 15:41 > =C0 : CHATRAS Bruno RD-CORE-ISS > Cc : martini@ietf.org > Objet : Re: [martini] Proposed work=20 > split:tackletelephone-numberregistration first >=20 > On the one hand, I agree we have to work on a general=20 > mechanism to enable the SP to provision IP PBXen as well as=20 > an efficient way for IP PBXen to register endpoints to an SP. >=20 > On the other hand, are you willing to wait 3-5 years for the=20 > general mechanism? More especially so given the industry=20 > today is 99.9% E.164 numbers and needs a solution last year?=20 > This is a serious question: if service providers are saying,=20 > "This is going to be important, but we really do not need a=20 > solution in 3-5 years," then that informs our > work: we can relax and engineer the perfect solution.=20=20 > However, almost all of the service providers I speak with=20 > say, "A solution to this problem is already a year late. If=20 > we do not see something soon [2-3 months] we are going to=20 > codify and deploy the (admittedly broken) REGISTER method=20 > that we are already using, with or without the IETF.=20=20 > It would be nice if we could have a not-so-broken mechanism,=20 > but the market has lost its patience." >=20 > Again, doing the E.164-only solution today does not mean we=20 > ignore the long-term problem. >=20 > Does this work for you? >=20 > On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: >=20 > > Hi, Bruno, > > > > My apologies for not snapping when I saw your e-mail address - I'm=20 > > currently chairing three working groups, and things are getting a=20 > > little blurry (MEDIACTRL *really* needs to finish soon!). > > > > Thanks for the input - it's helpful. > > > > Spencer > > > > ----- Original Message ----- From:=20 > > > To: ; ;=20 > > > >; > > Cc: > > Sent: Friday, January 29, 2010 7:39 AM > > Subject: RE: [martini] Proposed work split:tackletelephone-=20 > > numberregistration first > > > > > > Hi Spencer, > > > > I have seen you request on the sip-ops list where you noted that=20 > > MARTINI is not getting inputs from other operators (than CableLabs). > > I'm actually representing a fixed and mobile operator=20 > (France Telecom=20 > > - Orange) and as you can guess from my previous posts we support a=20 > > REGISTER-based solution and believe that a solution=20 > restricted to Tel=20 > > URIs would be of limited interest. > > > > /BC > > > > > > > >> -----Message d'origine----- > >> De : martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > >> Envoy=E9 : jeudi 28 janvier 2010 22:59 > >> =C0 : Brian Lindsay; Eric Burger; Dean Willis > >> Cc : martini@ietf.org > >> Objet : Re: [martini] Proposed work > >> split:tackletelephone-numberregistration first > >> > >> Hi, Brian, > >> > >> Thanks for the quick feedback. I'm mostly asking if I'm > >> reading where we are going correctly (I GOTTA get the draft > >> minutes out from that call!). > >> > >> This is kind of twisty-little-passages-all-alike/different > >> (for those of you that remember the "adventure" game in the > >> early 1980s), but I'm trying to follow the chain. Where I > >> thought we were, was that we didn't have a coherent story for > >> how we get a call from outside the service provider, to the > >> service provider, to the SIP-PBX, and I've heard a bunch of > >> smart guys talk for a long time on a number of occasions > >> about how that might work/not work, usually ending with "but > >> if this was limited to E.164 numbers, a lot of these problems > >> would go away". > >> > >> So I'm trying to laces comments from the call that I remember > >> together, and see what the resulting tapestry looks like. > >> > >> Tell you what. I'll go work on draft minutes and stop typing > >> e-mail, and we'll see if that works better :D > >> > >> Spencer > >> > >> ----- Original Message ----- > >> From: "Brian Lindsay" > >> To: "Spencer Dawkins" ; "Eric Burger" > >> ; "Dean Willis" > >> > >> Cc: > >> Sent: Thursday, January 28, 2010 3:48 PM > >> Subject: RE: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> > >> Hi Spencer, > >> > >> I am not sure if this is going down the path that the > >> actual register > >> request uses a Tel: URI. > >> > >> If so, I don't see why that needs to be the case. The > >> REGISTER itself > >> can still be done per Martini-Shaken with a SIP URI > >> representing the SIP > >> PBX. In fact, I am not sure too much has to change with Martini-=20 > >> Shaken > >> unless you want to enforce use of a Tel URI format for=20 > requests sent > >> towards the SIP PBX. > >> > >> Thanks > >> Brian > >> > >> > >> > >> -----Original Message----- > >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > >> Behalf Of Spencer Dawkins > >> Sent: Thursday, January 28, 2010 4:39 PM > >> To: Eric Burger; Dean Willis > >> Cc: martini@ietf.org > >> Subject: Re: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> OK, this discussion continues to be lovely. Thanks again for=20=20 > >> listening > >> to the people you're talking to ("plays well with others" is > >> under-appreciated, once we get out of primary school, but *I* > >> appreciate > >> it!) > >> > >> After reading this thread down through Eric's note below,=20 > I have a=20=20 > >> few > >> requests, as co-chair. > >> > >> We're talking about E.164 numbers like we can easily=20 > identify them.=20=20 > >> My > >> understanding from Tuesday's call was that people on the=20 > call thought > >> the only way we could unambiguously know that we had an E.164 > >> number was > >> if we had a tel: URI. If people on this list want to challenge that > >> assertion, this would be a great time to say so - please push > >> back Real > >> Soon Now. > >> > >> If that's true, we're talking about using Tel: URIs. Dean has=20=20 > >> asserted > >> that this would require an update to 3261. I'm not a genius > >> of 3261, but > >> some of you guys are - could you point us to what you think > >> needs to be > >> updated? > >> > >> My quick read turned up this text in Section 4, page 17: > >> > >> Registration is another common operation in SIP. > >> Registration is one > >> way that the biloxi.com server can learn the current > >> location of Bob. > >> Upon initialization, and at periodic intervals, Bob's SIP > >> phone sends > >> REGISTER messages to a server in the biloxi.com domain > >> known as a SIP > >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI > >> (sip:bob@biloxi.com) with the machine into which he is currently > >> logged (conveyed as a SIP or SIPS URI in the Contact=20 > header field). > >> > >> Dean, Is this what you were thinking of? Are there other=20 > places that > >> also need to change? > >> > >> As I read http://www.ietf.org/id/draft-peterson-rai-=20 > >> rfc3427bis-04.txt, > >> Section 2.1, this change would have to go through SIPCORE, > >> because it's > >> an update to 3261. If you know of obvious land mines that=20 > we would be > >> walking into if we propose this change, please say so Real=20 > Soon Now. > >> (One obvious land mine is that DISPATCH isn't meeting in > >> Anaheim, so the > >> proposal would have to be DISPATCHed on the mailing list in > >> order to do > >> something before IETF 78 - are there OTHERS?) > >> > >> Finally, if you believe that embracing tel: URIs is the=20 > wrong thing=20=20 > >> to > >> do, please say so, Real Soon Now. > >> > >> The milestones that we committed to in > >> http://tools.ietf.org/wg/martini/charters have us adopting=20 > a working > >> group SOLUTION draft in January. We're not late yet, but it's the=20= =20 > >> 28th > >> of January in my time zone. If we are late, where late is=20 > measured in > >> days, I can live with that, but if we are late, where late is=20=20 > >> measured > >> in IETF meeting cycles, that's going to be a problem. > >> > >> Thanks, > >> > >> Spencer, as co-chair > >> > >> ----- Original Message ----- > >> From: "Eric Burger" > >> To: "Dean Willis" > >> Cc: > >> Sent: Thursday, January 28, 2010 12:32 PM > >> Subject: Re: [martini] Proposed work split: tackle > >> telephone-numberregistration first > >> > >> > >> > If you ask me (why can't I stay in retirement?), the E.164=20=20 > >> situation > >> is > >> > not only a simplification, but just about the only thing that is > >> sensible > >> > for MARTINI to work on. > >> > > >> > The E.164 situation is a clear, present,=20 > industry-is-begging-for-a- > >> > solution problem. It is so pressing, the industry will tell us=20= =20 > >> (the > >> > IETF) to get stuffed and do something stupid if we cannot deliver > >> > something that is not at its core fundamentally broken. > >> > > >> > I do not think anyone can have an issue with mechanisms > >> that translate > >> a > >> > string of digits into an AOR that might cross domain boundaries. > >> This is > >> > the E.164 problem statement. > >> > > >> > If think everyone (with a brain) SHOULD have issues with a=20=20 > >> mechanism > >> that > >> > magically mungs "sip:eburger@neustar.biz" into > >> "sip:5350@pbx.example.net " > >> > while at the same time www.neustar.biz is really a neustar.biz > >> domain. > >> > That really would be creating a parallel DNS, which, as=20 > one of the > >> major > >> > DNS operators, would really, really be "less than ideal" and=20=20 > >> have a > >> whole > >> > host of security and integrity issues. > >> > > >> > THEREFORE, I would propose that we split this work into=20 > two phases: > >> > Phase 1: Deliver an E.164 solution, preferably in the next few > >> months, > >> > so the industry does not ignore the IETF. > >> > > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year=20= =20 > >> IETF > >> > cycle. This generic solution may or may not encompass > >> E.164 numbers. > >> As > >> > Doug Sauder points out, E.164 numbers and their=20 > infrastructure are > >> > different. Thus a different E.164 registration model from > >> generic SIP > >> > URI provisioning models would neither be a burden on industry nor > >> create > >> > backwards-compatibility issues for the generic solution. > >> > > >> > Note that if we do not deliver Phase 1 in a very, very > >> timely manner, > >> the > >> > less-than-idea industry solution just might blow up the=20=20=20 > >> possibility > >> for > >> > the generic solution, which would be considerably less=20=20 > than ideal. > >> > > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> > > >> >> > >> >> We seem to have an urgent need for a near-term solution for=20=20 > >> dealing > >> with > >> >> the subset of the MARTINI problem that, loosely defined, > >> covers the > >> >> "telephone number" problem. > >> >> > >> >> The typical scenario here is SIP trunking, wherein a SIP Service > >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a > >> customer's > >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch > >> of phone > >> >> numbers to the PBXes. This mapping is somewhat dynamic, > >> because the > >> >> PBXes usually have DHCP addresses, and don't have DNS entries=20= =20 > >> that > >> point > >> >> A records at the PBX in any sort of particularly useful way=20=20 > >> (maybe > >> >> something like dhcp-10-1-2-3- example.com). > >> >> > >> >> So what we need is a way for a PBX, when it reboots (or perhaps > >> >> periodically) to say to the SSP "Here I Am; You may now send any > >> calls > >> >> for my assigned phone numbers to my current Contact." > >> >> > >> >> This is indeed a "registration" problem, but it isn't=20=20 > >> necessarily a > >> >> "domain registration problem". The only reason domains get mixed > >> into > >> >> this scenario at all is that we sometimes encode telephone=20=20=20 > >> numbers > >> as > >> >> the user parts of SIP URIs, and those SIP URIs have a=20=20 > domain part > >> >> attached to them. > >> >> > >> >> More interestingly, this problem is a tiny subset of the whole > >> MARTINI > >> >> dynamic binding problem, and it potentially can be solved > >> much more > >> >> simply than the general problem. > >> >> > >> >> On today's Interim II call, Richard, Adam and I raised=20 > the idea of > >> >> dividing our problem space, and taking on a near-term=20 > milestone=20=20 > >> for > >> >> delivering a MARTINI solution for registering contacts=20 > to a proxy, > >> where > >> >> that proxy maps one or more telephone numbers to the contact. > >> >> > >> >> We certainly intend to go on and tackle the more general domain- > >> >> registration problem, but I (and I believe Adam and > >> Richard) believe > >> >> that we get a lot out of tackling the telephone-number > >> subset first. > >> >> > >> >> In particular, we believe that this approach solves many of the > >> domain > >> >> "responsibility" questions, simplifies the TLS keying/ > >> certification > >> >> model immensely, eliminates the cognitive overload of > >> using REGISTER > >> to > >> >> bind a "domain" to a Contact, "route authentication",=20 > and a good > >> many > >> >> other open issues that plague our current drafts. > >> >> > >> >> > >> >> Open questions relating to this approach include: > >> >> > >> >> 1) Do we deal only with E.164 numbers, or do we need to=20 > deal with > >> >> private-number "phone contexts"? > >> >> > >> >> 2) D owe need to explicitly encode the telephone numbers being > >> >> registered in the REGISTER request (either directly or through=20= =20 > >> some > >> sort > >> >> of regexp), or is it adequate to rely on provisioning of > >> the SSP and > >> PBX > >> >> (and any UAs) to statically bind the numbers to the PBX=20 > identity, > >> and > >> >> then dynamically only register the PBX identity to the > >> PBX contact? > >> >> > >> >> 3) Can we "register" with a tel: URI as the "To" value? (this=20=20 > >> seems > >> to > >> >> require extending RFC 3261)? Note that "tel:" can express > >> both E. 164 > >> >> numbers and private phone-contexts in one format. > >> >> > >> >> 4) What happens with GRUUs? > >> >> > >> >> I believe all of these issues are quite tractable, if=20 > we accept=20=20 > >> the > >> >> fundamental idea of splitting the phone-number problem=20 > off from=20=20 > >> the > >> more > >> >> general domain-registration, and recognize the possibility > >> that the > >> >> solutions to the two problem may reasonably be quite > >> different from > >> each > >> >> other. > >> >> > >> >> So, what do you people think? Is it worth trying to drink the > >> MARTINI > >> >> elephant one sip at a time, or are we going to treat the > >> whole thing > >> >> like a tequila shot and just slam it down? > >> >> > >> >> -- > >> >> Dean > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> martini mailing list > >> >> martini@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/martini > >> > > >> > _______________________________________________ > >> > martini mailing list > >> > martini@ietf.org > >> > https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > > > ********************************* > > This message and any attachments (the "message") are confidential=20=20 > > and intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if=20 > altered,=20=20 > > changed or falsified. > > If you are not the intended addressee of this message,=20 > please cancel=20=20 > > it immediately and inform the sender. > > ******************************** > > >=20 >=20 ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From adam@nostrum.com Fri Jan 29 08:39:31 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986A13A6A4B for ; Fri, 29 Jan 2010 08:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 GzTnT4LHm4e7 for ; Fri, 29 Jan 2010 08:39:30 -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 C28403A6A45 for ; Fri, 29 Jan 2010 08:39:29 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0TGdoPX089213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jan 2010 10:39:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B630F56.1020304@nostrum.com> Date: Fri, 29 Jan 2010 10:39:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: martini@ietf.org References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------020905000207000407040604" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 16:39:31 -0000 This is a multi-part message in MIME format. --------------020905000207000407040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/29/10 10:28 AM, bruno.chatras@orange-ftgroup.com wrote: > I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs. That's not really the major problem here. An incomplete list of the big issues off the top of my head are: 1. Changing the semantics of REGISTER to indicate more than one human breaks certain security (policy) assumptions at intermediaries. It may also cause problems with Path, Service-Route, and connection re-use (that is, they may not "just work", as previously claimed, due to changing security properties). 2. Changing the semantics of REGISTER (this is a different change) to mean "override RFC 3263 procedures with this mapping" instead of "add this AOR to Contact mapping to your database" breaks certain security assumptions at intermediaries. 3. Using a mechanism other than DNS (a mechanism that returns different results than DNS) to map from domain names to IP addresses is effectively creating a parallel DNS system, which runs afoul ICANN and IAB stated positions. 4. The current proposals don't clearly state who is "responsible" for a domain (as that terms is used in RFC 3261). Given that only the "responsible" party is allowed to retarget requests, problems arise with the basic model no matter who you choose as "responsible." 5. There is some debate about whether the AORs being registered need to be indicated in the transaction at all (either in the request or in the response). Having them appear solves two separate problems: (a) it allows detection of mismatches between the SSP's idea of which AORs have been registered and the PBX's, and (b) it allows intermediaries to determine which AORs the registration pertains to. Using the 3GPP/ETSI approach would lead to potentially large responses, which causes issues when UDP is employed. These are broad summaries -- the details of the problems have been given in prior emails and on the interim calls. There are also the flat-out obvious protocol violations in the 3GPP/ETSI solution as specified, such as the syntactic violation of using unescaped POSIX regexes where nameaddrs are to appear, and the semantic violation of pushing these regexes into reg-event notifications (which is broken regardless of whether you escape them). /a --------------020905000207000407040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/29/10 10:28 AM, bruno.chatras@orange-ftgroup.com wrote: 
I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs.

That's not really the major problem here. An incomplete list of the big issues off the top of my head are:
  1. Changing the semantics of REGISTER to indicate more than one human breaks certain security (policy) assumptions at intermediaries. It may also cause problems with Path, Service-Route, and connection re-use (that is, they may not "just work", as previously claimed, due to changing security properties).

  2. Changing the semantics of REGISTER (this is a different change) to mean "override RFC 3263 procedures with this mapping" instead of "add this AOR to Contact mapping to your database" breaks certain security assumptions at intermediaries.

  3. Using a mechanism other than DNS (a mechanism that returns different results than DNS) to map from domain names to IP addresses is effectively creating a parallel DNS system, which runs afoul ICANN and IAB stated positions.

  4. The current proposals don't clearly state who is "responsible" for a domain (as that terms is used in RFC 3261). Given that only the "responsible" party is allowed to retarget requests, problems arise with the basic model no matter who you choose as "responsible."

  5. There is some debate about whether the AORs being registered need to be indicated in the transaction at all (either in the request or in the response). Having them appear solves two separate problems: (a) it allows detection of mismatches between the SSP's idea of which AORs have been registered and the PBX's, and (b) it allows intermediaries to determine which AORs the registration pertains to. Using the 3GPP/ETSI approach would lead to potentially large responses, which causes issues when UDP is employed.

These are broad summaries -- the details of the problems have been given in prior emails and on the interim calls.

There are also the flat-out obvious protocol violations in the 3GPP/ETSI solution as specified, such as the syntactic violation of using unescaped POSIX regexes where nameaddrs are to appear, and the semantic violation of pushing these regexes into reg-event notifications (which is broken regardless of whether you escape them).

/a
--------------020905000207000407040604-- From john.elwell@siemens-enterprise.com Fri Jan 29 09:03:41 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894BF3A6A1E for ; Fri, 29 Jan 2010 09:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 2WibN3i-F-cd for ; Fri, 29 Jan 2010 09:03:40 -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 0B92C3A6A31 for ; Fri, 29 Jan 2010 09:03:38 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-718179; Fri, 29 Jan 2010 18:03:59 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E4D081EB82AB; Fri, 29 Jan 2010 18:03:59 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 29 Jan 2010 18:03:59 +0100 From: "Elwell, John" To: Adam Roach Date: Fri, 29 Jan 2010 18:03:58 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: Acqg/vepPTAadUv/QT+NSbEYGgKZOAABeCuw Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B6210AB.1050309@nostrum.com> <4B630AC5.7070203@nostrum.com> In-Reply-To: <4B630AC5.7070203@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:03:41 -0000 Agreed, but the assertion at least tells me the request came from estacado.= net. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 29 January 2010 16:20 > To: Elwell, John > Cc: Spencer Dawkins; martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > On 1/29/10 4:33 AM, Elwell, John wrote: > > Although outside the scope of what we are doing with=20 > SIPconnect at present, bear in mind that RFC 4474 cannot be=20 > used with a tel: URI. >=20 > It also doesn't do what people expect it to do when you use=20 > E.164-like=20 > identifiers in SIP URIs. I can easily make a valid RFC4474 assertion=20 > that I own the identity "sip:+441908855608@estacado.net;user=3Dphone".=20 > And, from a pure SIP perspective, it would be 100% true. >=20 > But it's probably a bit surprising. >=20 > /a > = From john.elwell@siemens-enterprise.com Fri Jan 29 09:22:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1423A6A4F for ; Fri, 29 Jan 2010 09:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 3dvofrpNRO4x for ; Fri, 29 Jan 2010 09:22:47 -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 299413A6837 for ; Fri, 29 Jan 2010 09:22:43 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-718430; Fri, 29 Jan 2010 18:23:06 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 09AF71EB82AB; Fri, 29 Jan 2010 18:23:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 29 Jan 2010 18:23:05 +0100 From: "Elwell, John" To: Spencer Dawkins , Paul Kyzivat Date: Fri, 29 Jan 2010 18:23:04 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: Acqg8R0kwmiQ5M5wSRqzNifq1s/d1QAFoB4A Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B62ED8D.9050503@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:22:47 -0000 =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 29 January 2010 14:41 > To: Paul Kyzivat > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > Hi, Paul, >=20 > A question, and a thank-you... >=20 > >> We're talking about E.164 numbers like we can easily=20 > identify them. My > >> understanding from Tuesday's call was that people on the=20 > call thought the > >> only way we could unambiguously know that we had an E.164=20 > number was if=20 > >> we > >> had a tel: URI. If people on this list want to challenge=20 > that assertion,=20 > >> this would > >> be a great time to say so - please push back Real Soon Now. > > > > I don't know that it is the *only* way, but it is an=20 > unambiguous way. > > > > Of course sip URIs *can* contain E.164 numbers. The trick=20 > is in ensuring=20 > > that everybody concerned agrees that's what they are. I=20 > think if the To of >=20 > I'm guessing that your phone rang about here, because the=20 > sentence just=20 > stopped. I think I know where you were headed, but wanted to=20 > make sure that=20 > I understood what you were thinking, because I appreciate you=20 > spending the=20 > time to be helpful here! Did you need to type a little more? >=20 > >> If that's true, we're talking about using Tel: URIs. Dean=20 > has asserted=20 > >> that this would require an update to 3261. I'm not a=20 > genius of 3261, but=20 > >> some of you guys are - could you point us to what you=20 > think needs to be=20 > >> updated? > > > > That would come up *if* the intent is to *explicitly*=20 > register a TEL URI.=20 > > The key issue is from section 10.2: > > > > To: The To header field contains the address of record whose > > registration is to be created, queried, or=20 > modified. The To > > header field and the Request-URI field typically=20 > differ, as > > the former contains a user name. This=20 > address-of-record MUST > > be a SIP URI or SIPS URI. > > > > But if the goal is to register using a SIP URI, and cause=20 > the "implicit=20 > > registration" of a number of TEL URIs, its not so clear=20 > that we have the=20 > > same problems with 3261. > > > > The more important issue is "constructing" an R-URI from a=20 > registered=20 > > contact address as a part of implicit registration, and=20 > ensuring that the=20 > > resulting URIs are unambiguous at the pbx. As long as the=20 > implicitly=20 > > registered AORs are all TEL URIs, or sip URIs with a TEL=20 > user part, then=20 > > the pbx can know what to expect as R-URIs for incoming=20 > requests. And it=20 > > can know that the URI for a given telephone number will be the same=20 > > regardless of what SSP it uses. > > > > (To ensure that, we would want to specify that the E.164 number was=20 > > represented in its canonical form, without any of the=20 > optional separator=20 > > characters.) >=20 > Yeah, I wondered if we were all talking about the same thing,=20 > when I was=20 > typing my note. I like your answer ("don't need to revise RFC=20 > 3261") better=20 > than the other answer. :-) >=20 > Do other people think we're talking about what Paul is talking about? [JRE] Yes, I think Paul sums it up nicely. John >=20 > Thanks, >=20 > Spencer=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From BLINDSAY@nortel.com Fri Jan 29 09:35:35 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2703A6917 for ; Fri, 29 Jan 2010 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 sl8BrTwYhb7R for ; Fri, 29 Jan 2010 09:35:34 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F199A3A680D for ; Fri, 29 Jan 2010 09:35:33 -0800 (PST) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o0THZms09485; Fri, 29 Jan 2010 17:35:48 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 12:35:46 -0500 Message-ID: <09B7DBFE70A9E24BBB21689DAD3A06141C4E61FD@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] Proposed worksplit: tackle telephone-numberregistration first Thread-Index: Acqg8R0kwmiQ5M5wSRqzNifq1s/d1QAFoB4AAAAlsZA= References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><4B62ED8D.9050503@cisco.com> From: "Brian Lindsay" To: "Elwell, John" , "Spencer Dawkins" , "Paul Kyzivat" Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 17:35:35 -0000 Hi, Just to chime in, I agree too. Per my note yesterday I don't think there is any need to explicitly register with a Tel URI. The MARTINI-Shaken approach of using a SIP URI representing the SIP PBX should be fine. The question would be how you want to represent the E.164 number in the request uri in requests to the SIP PBX (restrict to Tel URI or not). Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, January 29, 2010 12:23 PM To: Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit: tackle telephone-numberregistration first =20 > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 29 January 2010 14:41 > To: Paul Kyzivat > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle=20 > telephone-numberregistration first >=20 > Hi, Paul, >=20 > A question, and a thank-you... >=20 > >> We're talking about E.164 numbers like we can easily > identify them. My > >> understanding from Tuesday's call was that people on the > call thought the > >> only way we could unambiguously know that we had an E.164 > number was if > >> we > >> had a tel: URI. If people on this list want to challenge > that assertion, > >> this would > >> be a great time to say so - please push back Real Soon Now. > > > > I don't know that it is the *only* way, but it is an > unambiguous way. > > > > Of course sip URIs *can* contain E.164 numbers. The trick > is in ensuring > > that everybody concerned agrees that's what they are. I > think if the To of >=20 > I'm guessing that your phone rang about here, because the sentence=20 > just stopped. I think I know where you were headed, but wanted to make > sure that I understood what you were thinking, because I appreciate=20 > you spending the time to be helpful here! Did you need to type a=20 > little more? >=20 > >> If that's true, we're talking about using Tel: URIs. Dean > has asserted > >> that this would require an update to 3261. I'm not a > genius of 3261, but > >> some of you guys are - could you point us to what you > think needs to be > >> updated? > > > > That would come up *if* the intent is to *explicitly* > register a TEL URI.=20 > > The key issue is from section 10.2: > > > > To: The To header field contains the address of record whose > > registration is to be created, queried, or > modified. The To > > header field and the Request-URI field typically > differ, as > > the former contains a user name. This > address-of-record MUST > > be a SIP URI or SIPS URI. > > > > But if the goal is to register using a SIP URI, and cause > the "implicit > > registration" of a number of TEL URIs, its not so clear > that we have the > > same problems with 3261. > > > > The more important issue is "constructing" an R-URI from a > registered > > contact address as a part of implicit registration, and > ensuring that the > > resulting URIs are unambiguous at the pbx. As long as the > implicitly > > registered AORs are all TEL URIs, or sip URIs with a TEL > user part, then > > the pbx can know what to expect as R-URIs for incoming > requests. And it > > can know that the URI for a given telephone number will be the same=20 > > regardless of what SSP it uses. > > > > (To ensure that, we would want to specify that the E.164 number was=20 > > represented in its canonical form, without any of the > optional separator > > characters.) >=20 > Yeah, I wondered if we were all talking about the same thing, when I=20 > was typing my note. I like your answer ("don't need to revise RFC > 3261") better > than the other answer. :-) >=20 > Do other people think we're talking about what Paul is talking about? [JRE] Yes, I think Paul sums it up nicely. John >=20 > Thanks, >=20 > Spencer >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Fri Jan 29 10:03:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917E228C176 for ; Fri, 29 Jan 2010 10:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 WmOJrCwWZk7r for ; Fri, 29 Jan 2010 10:03:12 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D7D8A28C175 for ; Fri, 29 Jan 2010 10:01:51 -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; Fri, 29 Jan 2010 13:02:13 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 29 Jan 2010 13:02:13 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 29 Jan 2010 13:02:12 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registration first Thread-Index: AcqgQpC95gL1oP15SPS/9J5ciSflFQAymqCg Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <4B61CE78.20605@cisco.com> In-Reply-To: <4B61CE78.20605@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: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:03:13 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 28, 2010 12:51 PM > To: Hadriel Kaplan >=20 > Claiming ownership doesn't mean that you will be granted ownership. > In the case of phone numbers, I have been assuming that the SSP knows > which numbers it has control over, and which have been contractually > agreed to be delegated to the PBX. >=20 > But the SSP isn't in charge of domain names. > If I register with the SSP and say I want to receive requests for > whitehouse.gov, how can it determine if that is proper or not? >=20 > It could if *it* registered the domain names on behalf of the customers. > But if the customer says to the SSP "I already own this domain and will > arrange for requests to it to be routed to you, so when you get them > please forward them on to my pbx", how is the SSP to decide if that is > ok or not? Ummm, not to belabor the idea of using domain name registration (though her= e I am belaboring it), but it *is* a domain owned by the SSP. At least tha= t's what draft-shaken says. -hadriel From richard@shockey.us Fri Jan 29 10:25:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1693A6359 for ; Fri, 29 Jan 2010 10:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, 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 W2mAPMCdz4zp for ; Fri, 29 Jan 2010 10:25:35 -0800 (PST) Received: from outbound-mail-351.bluehost.com (outbound-mail-351.bluehost.com [66.147.249.12]) by core3.amsl.com (Postfix) with SMTP id 3FAD23A659C for ; Fri, 29 Jan 2010 10:25:35 -0800 (PST) Received: (qmail 18358 invoked by uid 0); 29 Jan 2010 18:25:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy7.bluehost.com.bluehost.com with SMTP; 29 Jan 2010 18:25:57 -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=LHdGdLh2iJn/JIBpCBEbF070/cLyw4dYsgkBn1clhjIcdkkjfBzJqXgi08xlELoHnixfMWmRf5TmrhunFNS8xzJ3T5MluBi3+QMSQCMe37sicFJE3kEXZl16Ut7L4zeG; 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 1NavXY-0001IT-G2; Fri, 29 Jan 2010 11:25:57 -0700 From: "Richard Shockey" To: "'Brian Lindsay'" , "'Elwell, John'" , "'Spencer Dawkins'" , "'Paul Kyzivat'" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><4B62ED8D.9050503@cisco.com> <09B7DBFE70A9E24BBB21689DAD3A06141C4E61FD@zcarhxm1.corp.nortel.com> In-Reply-To: <09B7DBFE70A9E24BBB21689DAD3A06141C4E61FD@zcarhxm1.corp.nortel.com> Date: Fri, 29 Jan 2010 13:25:51 -0500 Message-ID: <002701caa110$7f1239d0$7d36ad70$@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: Acqg8R0kwmiQ5M5wSRqzNifq1s/d1QAFoB4AAAAlsZAAAgDq8A== 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: martini@ietf.org Subject: Re: [martini] Proposed worksplit: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:25:39 -0000 +1 plus it seems obvious to me that the proper direction of MARTINI is to fix what is in the field now without potentially breaking a long term solution in the future. We all want SIP URI's to be the dominant form of addressing. -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Brian Lindsay Sent: Friday, January 29, 2010 12:36 PM To: Elwell, John; Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit: tackle telephone-numberregistration first Hi, Just to chime in, I agree too. Per my note yesterday I don't think there is any need to explicitly register with a Tel URI. The MARTINI-Shaken approach of using a SIP URI representing the SIP PBX should be fine. The question would be how you want to represent the E.164 number in the request uri in requests to the SIP PBX (restrict to Tel URI or not). Thanks Brian -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: Friday, January 29, 2010 12:23 PM To: Spencer Dawkins; Paul Kyzivat Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit: tackle telephone-numberregistration first > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Spencer Dawkins > Sent: 29 January 2010 14:41 > To: Paul Kyzivat > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work split: tackle > telephone-numberregistration first > > Hi, Paul, > > A question, and a thank-you... > > >> We're talking about E.164 numbers like we can easily > identify them. My > >> understanding from Tuesday's call was that people on the > call thought the > >> only way we could unambiguously know that we had an E.164 > number was if > >> we > >> had a tel: URI. If people on this list want to challenge > that assertion, > >> this would > >> be a great time to say so - please push back Real Soon Now. > > > > I don't know that it is the *only* way, but it is an > unambiguous way. > > > > Of course sip URIs *can* contain E.164 numbers. The trick > is in ensuring > > that everybody concerned agrees that's what they are. I > think if the To of > > I'm guessing that your phone rang about here, because the sentence > just stopped. I think I know where you were headed, but wanted to make > sure that I understood what you were thinking, because I appreciate > you spending the time to be helpful here! Did you need to type a > little more? > > >> If that's true, we're talking about using Tel: URIs. Dean > has asserted > >> that this would require an update to 3261. I'm not a > genius of 3261, but > >> some of you guys are - could you point us to what you > think needs to be > >> updated? > > > > That would come up *if* the intent is to *explicitly* > register a TEL URI. > > The key issue is from section 10.2: > > > > To: The To header field contains the address of record whose > > registration is to be created, queried, or > modified. The To > > header field and the Request-URI field typically > differ, as > > the former contains a user name. This > address-of-record MUST > > be a SIP URI or SIPS URI. > > > > But if the goal is to register using a SIP URI, and cause > the "implicit > > registration" of a number of TEL URIs, its not so clear > that we have the > > same problems with 3261. > > > > The more important issue is "constructing" an R-URI from a > registered > > contact address as a part of implicit registration, and > ensuring that the > > resulting URIs are unambiguous at the pbx. As long as the > implicitly > > registered AORs are all TEL URIs, or sip URIs with a TEL > user part, then > > the pbx can know what to expect as R-URIs for incoming > requests. And it > > can know that the URI for a given telephone number will be the same > > regardless of what SSP it uses. > > > > (To ensure that, we would want to specify that the E.164 number was > > represented in its canonical form, without any of the > optional separator > > characters.) > > Yeah, I wondered if we were all talking about the same thing, when I > was typing my note. I like your answer ("don't need to revise RFC > 3261") better > than the other answer. :-) > > Do other people think we're talking about what Paul is talking about? [JRE] Yes, I think Paul sums it up nicely. John > > Thanks, > > Spencer > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From HKaplan@acmepacket.com Fri Jan 29 10:38:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE4B3A6A35 for ; Fri, 29 Jan 2010 10:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIJwE+6-I-c8 for ; Fri, 29 Jan 2010 10:37:59 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4CBC93A693D for ; Fri, 29 Jan 2010 10:37:59 -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; Fri, 29 Jan 2010 13:38:21 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 29 Jan 2010 13:38:21 -0500 From: Hadriel Kaplan To: Spencer Dawkins , Eric Burger , Dean Willis Date: Fri, 29 Jan 2010 13:38:19 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqgYna0gu+vFwK0RKOSZA5PUEtdswAqxhjg Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.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: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:38:00 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Spencer Dawkins > Sent: Thursday, January 28, 2010 4:39 PM > To: Eric Burger; Dean Willis >=20 > Finally, if you believe that embracing tel: URIs is the wrong thing to do= , > please say so, Real Soon Now. I think it's the wrong thing to do. It doesn't magically fix anything - it= just lets us pretend the issues don't exist, when they either still do, or= didn't either for draft-shaken, as follows: =20 a) What is the Req-URI going to be for a request when it reaches the regis= trar-proxy (RP) on its way to the PBX? It's going to be sip:12345@ssp.com.= What does the RP need to do to it? Retarget to URI's of the PBX. That's= what we needed to do even with a draft-shaken model. b) What happens if the RP gets a request for sip:12345@pbx.com? With Tel-= URI we're going to claim that can't happen, or it's out of scope, or whatev= er. Great! Let's just claim that for draft-shaken too. Claiming things a= re out of scope makes life easy. c) What are the security issues of a PBX Registering an AoR of tel:12345? = Well, in theory it's claiming to represent a global URI. We assume that t= he SSP has the moral authority to approve/disapprove that claim. Why? Bec= ause presumably 12345 is actually assigned to SSP. Great! So draft-shaken= Registers sip:foobar@ssp.com - guess who owns ssp.com? The SSP! So how w= as that broken again?? d) There was some concern about the various forms the identities of the PB= X users could appear as, for example with or without leading + and country-= codes, etc. Those aren't going away with a tel URI. e) One of the major sticking points was whether the req- URI is replaced with the Registered contact, or left alone, or just retarge= ted. Using a Tel-URI AoR makes that no easier a decision/argument/issue. f) One of the concerns raised so far has been on GRUU's. Unless we figure= out how to convert GRUU's to telephone numbers, there's going to be a need= to route a request for a non-TEL-URI to the PBX and keep it a non-TEL-URI. -hadriel From HKaplan@acmepacket.com Fri Jan 29 10:47:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348DE3A67E5 for ; Fri, 29 Jan 2010 10:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 1z8penbx4o4U for ; Fri, 29 Jan 2010 10:47:27 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 38D5F3A6A61 for ; Fri, 29 Jan 2010 10:47:27 -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; Fri, 29 Jan 2010 13:47:49 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 29 Jan 2010 13:47:49 -0500 From: Hadriel Kaplan To: Paul Kyzivat , Adam Roach Date: Fri, 29 Jan 2010 13:47:48 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-number registrationfirst Thread-Index: Acqg8aduwZxxLK45TVmHrhkf0oJWRAAIR2AA Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> <4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> In-Reply-To: <4B62F45D.1010707@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: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 18:47:28 -0000 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: Friday, January 29, 2010 9:45 AM > To: Adam Roach >=20 > This may be slightly out of scope, but when TEL URIs are used in From, > To, Refer-To, etc. then there is no need to deal with issues of whether > to use the domain of the pbx, or the ssp, or to translate between them. Au contraire. The SSP registrar-proxy will be receiving requests ultimatel= y destined to the PBX containing SIP URI's in req-URI, To, Refer-To, etc. = Thus they will either show up at the PBX, or the SSP will have to perform t= he "mapping" function we claim isn't going to be necessary with Tel-URI's. = There is no getting away from this "mapping" function. -hadriel From drage@alcatel-lucent.com Fri Jan 29 12:17:24 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024BA3A67D4 for ; Fri, 29 Jan 2010 12:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 A4SRc9f-Wshk for ; Fri, 29 Jan 2010 12:17:22 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 8D06C3A686C for ; Fri, 29 Jan 2010 12:17:21 -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.14.3/8.14.3/ICT) with ESMTP id o0TKHgBw001486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Jan 2010 21:17:42 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 29 Jan 2010 21:17:42 +0100 From: "DRAGE, Keith (Keith)" To: Eric Burger , "bruno.chatras@orange-ftgroup.com" Date: Fri, 29 Jan 2010 21:15:44 +0100 Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: Acqg8SOnJoy7PGNpQpqpCyGEkpv8MgALpOlQ Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 20:17:24 -0000 Is the market today 100% tel URIs or is it 100% telephone numbers masquerad= ing as SIP URIs? regards Keith > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Friday, January 29, 2010 2:41 PM > To: bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work > split:tackletelephone-numberregistration first > > On the one hand, I agree we have to work on a general > mechanism to enable the SP to provision IP PBXen as well as > an efficient way for IP PBXen to register endpoints to an SP. > > On the other hand, are you willing to wait 3-5 years for the > general mechanism? More especially so given the industry > today is 99.9% E.164 numbers and needs a solution last year? > This is a serious question: if service providers are saying, > "This is going to be important, but we really do not need a > solution in 3-5 years," then that informs our > work: we can relax and engineer the perfect solution. > However, almost all of the service providers I speak with > say, "A solution to this problem is already a year late. If > we do not see something soon [2-3 months] we are going to > codify and deploy the (admittedly broken) REGISTER method > that we are already using, with or without the IETF. > It would be nice if we could have a not-so-broken mechanism, > but the market has lost its patience." > > Again, doing the E.164-only solution today does not mean we > ignore the long-term problem. > > Does this work for you? > > On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: > > > Hi, Bruno, > > > > My apologies for not snapping when I saw your e-mail address - I'm > > currently chairing three working groups, and things are getting a > > little blurry (MEDIACTRL *really* needs to finish soon!). > > > > Thanks for the input - it's helpful. > > > > Spencer > > > > ----- Original Message ----- From: > > > To: ; ; > > > >; > > Cc: > > Sent: Friday, January 29, 2010 7:39 AM > > Subject: RE: [martini] Proposed work split:tackletelephone- > > numberregistration first > > > > > > Hi Spencer, > > > > I have seen you request on the sip-ops list where you noted that > > MARTINI is not getting inputs from other operators (than CableLabs). > > I'm actually representing a fixed and mobile operator > (France Telecom > > - Orange) and as you can guess from my previous posts we support a > > REGISTER-based solution and believe that a solution > restricted to Tel > > URIs would be of limited interest. > > > > /BC > > > > > > > >> -----Message d'origine----- > >> De : martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > >> Envoy=E9 : jeudi 28 janvier 2010 22:59 > >> =C0 : Brian Lindsay; Eric Burger; Dean Willis > >> Cc : martini@ietf.org > >> Objet : Re: [martini] Proposed work > >> split:tackletelephone-numberregistration first > >> > >> Hi, Brian, > >> > >> Thanks for the quick feedback. I'm mostly asking if I'm > >> reading where we are going correctly (I GOTTA get the draft > >> minutes out from that call!). > >> > >> This is kind of twisty-little-passages-all-alike/different > >> (for those of you that remember the "adventure" game in the > >> early 1980s), but I'm trying to follow the chain. Where I > >> thought we were, was that we didn't have a coherent story for > >> how we get a call from outside the service provider, to the > >> service provider, to the SIP-PBX, and I've heard a bunch of > >> smart guys talk for a long time on a number of occasions > >> about how that might work/not work, usually ending with "but > >> if this was limited to E.164 numbers, a lot of these problems > >> would go away". > >> > >> So I'm trying to laces comments from the call that I remember > >> together, and see what the resulting tapestry looks like. > >> > >> Tell you what. I'll go work on draft minutes and stop typing > >> e-mail, and we'll see if that works better :D > >> > >> Spencer > >> > >> ----- Original Message ----- > >> From: "Brian Lindsay" > >> To: "Spencer Dawkins" ; "Eric Burger" > >> ; "Dean Willis" > >> > >> Cc: > >> Sent: Thursday, January 28, 2010 3:48 PM > >> Subject: RE: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> > >> Hi Spencer, > >> > >> I am not sure if this is going down the path that the > >> actual register > >> request uses a Tel: URI. > >> > >> If so, I don't see why that needs to be the case. The > >> REGISTER itself > >> can still be done per Martini-Shaken with a SIP URI > >> representing the SIP > >> PBX. In fact, I am not sure too much has to change with Martini- > >> Shaken > >> unless you want to enforce use of a Tel URI format for > requests sent > >> towards the SIP PBX. > >> > >> Thanks > >> Brian > >> > >> > >> > >> -----Original Message----- > >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > >> Behalf Of Spencer Dawkins > >> Sent: Thursday, January 28, 2010 4:39 PM > >> To: Eric Burger; Dean Willis > >> Cc: martini@ietf.org > >> Subject: Re: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> OK, this discussion continues to be lovely. Thanks again for > >> listening > >> to the people you're talking to ("plays well with others" is > >> under-appreciated, once we get out of primary school, but *I* > >> appreciate > >> it!) > >> > >> After reading this thread down through Eric's note below, > I have a > >> few > >> requests, as co-chair. > >> > >> We're talking about E.164 numbers like we can easily > identify them. > >> My > >> understanding from Tuesday's call was that people on the > call thought > >> the only way we could unambiguously know that we had an E.164 > >> number was > >> if we had a tel: URI. If people on this list want to challenge that > >> assertion, this would be a great time to say so - please push > >> back Real > >> Soon Now. > >> > >> If that's true, we're talking about using Tel: URIs. Dean has > >> asserted > >> that this would require an update to 3261. I'm not a genius > >> of 3261, but > >> some of you guys are - could you point us to what you think > >> needs to be > >> updated? > >> > >> My quick read turned up this text in Section 4, page 17: > >> > >> Registration is another common operation in SIP. > >> Registration is one > >> way that the biloxi.com server can learn the current > >> location of Bob. > >> Upon initialization, and at periodic intervals, Bob's SIP > >> phone sends > >> REGISTER messages to a server in the biloxi.com domain > >> known as a SIP > >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI > >> (sip:bob@biloxi.com) with the machine into which he is currently > >> logged (conveyed as a SIP or SIPS URI in the Contact > header field). > >> > >> Dean, Is this what you were thinking of? Are there other > places that > >> also need to change? > >> > >> As I read http://www.ietf.org/id/draft-peterson-rai- > >> rfc3427bis-04.txt, > >> Section 2.1, this change would have to go through SIPCORE, > >> because it's > >> an update to 3261. If you know of obvious land mines that > we would be > >> walking into if we propose this change, please say so Real > Soon Now. > >> (One obvious land mine is that DISPATCH isn't meeting in > >> Anaheim, so the > >> proposal would have to be DISPATCHed on the mailing list in > >> order to do > >> something before IETF 78 - are there OTHERS?) > >> > >> Finally, if you believe that embracing tel: URIs is the > wrong thing > >> to > >> do, please say so, Real Soon Now. > >> > >> The milestones that we committed to in > >> http://tools.ietf.org/wg/martini/charters have us adopting > a working > >> group SOLUTION draft in January. We're not late yet, but it's the > >> 28th > >> of January in my time zone. If we are late, where late is > measured in > >> days, I can live with that, but if we are late, where late is > >> measured > >> in IETF meeting cycles, that's going to be a problem. > >> > >> Thanks, > >> > >> Spencer, as co-chair > >> > >> ----- Original Message ----- > >> From: "Eric Burger" > >> To: "Dean Willis" > >> Cc: > >> Sent: Thursday, January 28, 2010 12:32 PM > >> Subject: Re: [martini] Proposed work split: tackle > >> telephone-numberregistration first > >> > >> > >> > If you ask me (why can't I stay in retirement?), the E.164 > >> situation > >> is > >> > not only a simplification, but just about the only thing that is > >> sensible > >> > for MARTINI to work on. > >> > > >> > The E.164 situation is a clear, present, > industry-is-begging-for-a- > >> > solution problem. It is so pressing, the industry will tell us > >> (the > >> > IETF) to get stuffed and do something stupid if we cannot deliver > >> > something that is not at its core fundamentally broken. > >> > > >> > I do not think anyone can have an issue with mechanisms > >> that translate > >> a > >> > string of digits into an AOR that might cross domain boundaries. > >> This is > >> > the E.164 problem statement. > >> > > >> > If think everyone (with a brain) SHOULD have issues with a > >> mechanism > >> that > >> > magically mungs "sip:eburger@neustar.biz" into > >> "sip:5350@pbx.example.net " > >> > while at the same time www.neustar.biz is really a neustar.biz > >> domain. > >> > That really would be creating a parallel DNS, which, as > one of the > >> major > >> > DNS operators, would really, really be "less than ideal" and > >> have a > >> whole > >> > host of security and integrity issues. > >> > > >> > THEREFORE, I would propose that we split this work into > two phases: > >> > Phase 1: Deliver an E.164 solution, preferably in the next few > >> months, > >> > so the industry does not ignore the IETF. > >> > > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year > >> IETF > >> > cycle. This generic solution may or may not encompass > >> E.164 numbers. > >> As > >> > Doug Sauder points out, E.164 numbers and their > infrastructure are > >> > different. Thus a different E.164 registration model from > >> generic SIP > >> > URI provisioning models would neither be a burden on industry nor > >> create > >> > backwards-compatibility issues for the generic solution. > >> > > >> > Note that if we do not deliver Phase 1 in a very, very > >> timely manner, > >> the > >> > less-than-idea industry solution just might blow up the > >> possibility > >> for > >> > the generic solution, which would be considerably less > than ideal. > >> > > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> > > >> >> > >> >> We seem to have an urgent need for a near-term solution for > >> dealing > >> with > >> >> the subset of the MARTINI problem that, loosely defined, > >> covers the > >> >> "telephone number" problem. > >> >> > >> >> The typical scenario here is SIP trunking, wherein a SIP Service > >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a > >> customer's > >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch > >> of phone > >> >> numbers to the PBXes. This mapping is somewhat dynamic, > >> because the > >> >> PBXes usually have DHCP addresses, and don't have DNS entries > >> that > >> point > >> >> A records at the PBX in any sort of particularly useful way > >> (maybe > >> >> something like dhcp-10-1-2-3- example.com). > >> >> > >> >> So what we need is a way for a PBX, when it reboots (or perhaps > >> >> periodically) to say to the SSP "Here I Am; You may now send any > >> calls > >> >> for my assigned phone numbers to my current Contact." > >> >> > >> >> This is indeed a "registration" problem, but it isn't > >> necessarily a > >> >> "domain registration problem". The only reason domains get mixed > >> into > >> >> this scenario at all is that we sometimes encode telephone > >> numbers > >> as > >> >> the user parts of SIP URIs, and those SIP URIs have a > domain part > >> >> attached to them. > >> >> > >> >> More interestingly, this problem is a tiny subset of the whole > >> MARTINI > >> >> dynamic binding problem, and it potentially can be solved > >> much more > >> >> simply than the general problem. > >> >> > >> >> On today's Interim II call, Richard, Adam and I raised > the idea of > >> >> dividing our problem space, and taking on a near-term > milestone > >> for > >> >> delivering a MARTINI solution for registering contacts > to a proxy, > >> where > >> >> that proxy maps one or more telephone numbers to the contact. > >> >> > >> >> We certainly intend to go on and tackle the more general domain- > >> >> registration problem, but I (and I believe Adam and > >> Richard) believe > >> >> that we get a lot out of tackling the telephone-number > >> subset first. > >> >> > >> >> In particular, we believe that this approach solves many of the > >> domain > >> >> "responsibility" questions, simplifies the TLS keying/ > >> certification > >> >> model immensely, eliminates the cognitive overload of > >> using REGISTER > >> to > >> >> bind a "domain" to a Contact, "route authentication", > and a good > >> many > >> >> other open issues that plague our current drafts. > >> >> > >> >> > >> >> Open questions relating to this approach include: > >> >> > >> >> 1) Do we deal only with E.164 numbers, or do we need to > deal with > >> >> private-number "phone contexts"? > >> >> > >> >> 2) D owe need to explicitly encode the telephone numbers being > >> >> registered in the REGISTER request (either directly or through > >> some > >> sort > >> >> of regexp), or is it adequate to rely on provisioning of > >> the SSP and > >> PBX > >> >> (and any UAs) to statically bind the numbers to the PBX > identity, > >> and > >> >> then dynamically only register the PBX identity to the > >> PBX contact? > >> >> > >> >> 3) Can we "register" with a tel: URI as the "To" value? (this > >> seems > >> to > >> >> require extending RFC 3261)? Note that "tel:" can express > >> both E. 164 > >> >> numbers and private phone-contexts in one format. > >> >> > >> >> 4) What happens with GRUUs? > >> >> > >> >> I believe all of these issues are quite tractable, if > we accept > >> the > >> >> fundamental idea of splitting the phone-number problem > off from > >> the > >> more > >> >> general domain-registration, and recognize the possibility > >> that the > >> >> solutions to the two problem may reasonably be quite > >> different from > >> each > >> >> other. > >> >> > >> >> So, what do you people think? Is it worth trying to drink the > >> MARTINI > >> >> elephant one sip at a time, or are we going to treat the > >> whole thing > >> >> like a tequila shot and just slam it down? > >> >> > >> >> -- > >> >> Dean > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> martini mailing list > >> >> martini@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/martini > >> > > >> > _______________________________________________ > >> > martini mailing list > >> > martini@ietf.org > >> > https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > > > ********************************* > > This message and any attachments (the "message") are confidential > > and intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if > altered, > > changed or falsified. > > If you are not the intended addressee of this message, > please cancel > > it immediately and inform the sender. > > ******************************** > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From richard@shockey.us Fri Jan 29 13:02:30 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D66F33A659A for ; Fri, 29 Jan 2010 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, 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 P3DhiymkNhXD for ; Fri, 29 Jan 2010 13:02:28 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 881A03A6889 for ; Fri, 29 Jan 2010 13:02:28 -0800 (PST) Received: (qmail 28999 invoked by uid 0); 29 Jan 2010 21:02:49 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by outboundproxy8.bluehost.com.bluehost.com with SMTP; 29 Jan 2010 21:02:49 -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=h9JBFDqIrxsUuM3U2oz7P38tJ6AGySjiQF6YtldBPVMEcAndqcK3pXjjy5yLTELDgw3JqDk4kiWEdSzkKdv+r+wMgojPEFh/6wPh4MoVUZvaHMUQOZY9BFHSk6mtElM2; 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 1NaxzM-0006Ei-Jq; Fri, 29 Jan 2010 14:02:49 -0700 From: "Richard Shockey" To: "'DRAGE, Keith \(Keith\)'" , "'Eric Burger'" , References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> In-Reply-To: Date: Fri, 29 Jan 2010 16:02:46 -0500 Message-ID: <003c01caa126$693153b0$3b93fb10$@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: Acqg8SOnJoy7PGNpQpqpCyGEkpv8MgALpOlQAAGpFDA= 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: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 21:02:31 -0000 The latter ... as far as I've able to determine -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of DRAGE, Keith (Keith) Sent: Friday, January 29, 2010 3:16 PM To: Eric Burger; bruno.chatras@orange-ftgroup.com Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first Is the market today 100% tel URIs or is it 100% telephone numbers masquerading as SIP URIs? regards Keith > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of Eric Burger > Sent: Friday, January 29, 2010 2:41 PM > To: bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work > split:tackletelephone-numberregistration first > > On the one hand, I agree we have to work on a general > mechanism to enable the SP to provision IP PBXen as well as > an efficient way for IP PBXen to register endpoints to an SP. > > On the other hand, are you willing to wait 3-5 years for the > general mechanism? More especially so given the industry > today is 99.9% E.164 numbers and needs a solution last year? > This is a serious question: if service providers are saying, > "This is going to be important, but we really do not need a > solution in 3-5 years," then that informs our > work: we can relax and engineer the perfect solution. > However, almost all of the service providers I speak with > say, "A solution to this problem is already a year late. If > we do not see something soon [2-3 months] we are going to > codify and deploy the (admittedly broken) REGISTER method > that we are already using, with or without the IETF. > It would be nice if we could have a not-so-broken mechanism, > but the market has lost its patience." > > Again, doing the E.164-only solution today does not mean we > ignore the long-term problem. > > Does this work for you? > > On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: > > > Hi, Bruno, > > > > My apologies for not snapping when I saw your e-mail address - I'm > > currently chairing three working groups, and things are getting a > > little blurry (MEDIACTRL *really* needs to finish soon!). > > > > Thanks for the input - it's helpful. > > > > Spencer > > > > ----- Original Message ----- From: > > > To: ; ; > > > >; > > Cc: > > Sent: Friday, January 29, 2010 7:39 AM > > Subject: RE: [martini] Proposed work split:tackletelephone- > > numberregistration first > > > > > > Hi Spencer, > > > > I have seen you request on the sip-ops list where you noted that > > MARTINI is not getting inputs from other operators (than CableLabs). > > I'm actually representing a fixed and mobile operator > (France Telecom > > - Orange) and as you can guess from my previous posts we support a > > REGISTER-based solution and believe that a solution > restricted to Tel > > URIs would be of limited interest. > > > > /BC > > > > > > > >> -----Message d'origine----- > >> De : martini-bounces@ietf.org > >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > >> Envoy=E9 : jeudi 28 janvier 2010 22:59 > >> =C0 : Brian Lindsay; Eric Burger; Dean Willis > >> Cc : martini@ietf.org > >> Objet : Re: [martini] Proposed work > >> split:tackletelephone-numberregistration first > >> > >> Hi, Brian, > >> > >> Thanks for the quick feedback. I'm mostly asking if I'm > >> reading where we are going correctly (I GOTTA get the draft > >> minutes out from that call!). > >> > >> This is kind of twisty-little-passages-all-alike/different > >> (for those of you that remember the "adventure" game in the > >> early 1980s), but I'm trying to follow the chain. Where I > >> thought we were, was that we didn't have a coherent story for > >> how we get a call from outside the service provider, to the > >> service provider, to the SIP-PBX, and I've heard a bunch of > >> smart guys talk for a long time on a number of occasions > >> about how that might work/not work, usually ending with "but > >> if this was limited to E.164 numbers, a lot of these problems > >> would go away". > >> > >> So I'm trying to laces comments from the call that I remember > >> together, and see what the resulting tapestry looks like. > >> > >> Tell you what. I'll go work on draft minutes and stop typing > >> e-mail, and we'll see if that works better :D > >> > >> Spencer > >> > >> ----- Original Message ----- > >> From: "Brian Lindsay" > >> To: "Spencer Dawkins" ; "Eric Burger" > >> ; "Dean Willis" > >> > >> Cc: > >> Sent: Thursday, January 28, 2010 3:48 PM > >> Subject: RE: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> > >> Hi Spencer, > >> > >> I am not sure if this is going down the path that the > >> actual register > >> request uses a Tel: URI. > >> > >> If so, I don't see why that needs to be the case. The > >> REGISTER itself > >> can still be done per Martini-Shaken with a SIP URI > >> representing the SIP > >> PBX. In fact, I am not sure too much has to change with Martini- > >> Shaken > >> unless you want to enforce use of a Tel URI format for > requests sent > >> towards the SIP PBX. > >> > >> Thanks > >> Brian > >> > >> > >> > >> -----Original Message----- > >> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On > >> Behalf Of Spencer Dawkins > >> Sent: Thursday, January 28, 2010 4:39 PM > >> To: Eric Burger; Dean Willis > >> Cc: martini@ietf.org > >> Subject: Re: [martini] Proposed work split: > >> tackletelephone-numberregistration first > >> > >> OK, this discussion continues to be lovely. Thanks again for > >> listening > >> to the people you're talking to ("plays well with others" is > >> under-appreciated, once we get out of primary school, but *I* > >> appreciate > >> it!) > >> > >> After reading this thread down through Eric's note below, > I have a > >> few > >> requests, as co-chair. > >> > >> We're talking about E.164 numbers like we can easily > identify them. > >> My > >> understanding from Tuesday's call was that people on the > call thought > >> the only way we could unambiguously know that we had an E.164 > >> number was > >> if we had a tel: URI. If people on this list want to challenge that > >> assertion, this would be a great time to say so - please push > >> back Real > >> Soon Now. > >> > >> If that's true, we're talking about using Tel: URIs. Dean has > >> asserted > >> that this would require an update to 3261. I'm not a genius > >> of 3261, but > >> some of you guys are - could you point us to what you think > >> needs to be > >> updated? > >> > >> My quick read turned up this text in Section 4, page 17: > >> > >> Registration is another common operation in SIP. > >> Registration is one > >> way that the biloxi.com server can learn the current > >> location of Bob. > >> Upon initialization, and at periodic intervals, Bob's SIP > >> phone sends > >> REGISTER messages to a server in the biloxi.com domain > >> known as a SIP > >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI > >> (sip:bob@biloxi.com) with the machine into which he is currently > >> logged (conveyed as a SIP or SIPS URI in the Contact > header field). > >> > >> Dean, Is this what you were thinking of? Are there other > places that > >> also need to change? > >> > >> As I read http://www.ietf.org/id/draft-peterson-rai- > >> rfc3427bis-04.txt, > >> Section 2.1, this change would have to go through SIPCORE, > >> because it's > >> an update to 3261. If you know of obvious land mines that > we would be > >> walking into if we propose this change, please say so Real > Soon Now. > >> (One obvious land mine is that DISPATCH isn't meeting in > >> Anaheim, so the > >> proposal would have to be DISPATCHed on the mailing list in > >> order to do > >> something before IETF 78 - are there OTHERS?) > >> > >> Finally, if you believe that embracing tel: URIs is the > wrong thing > >> to > >> do, please say so, Real Soon Now. > >> > >> The milestones that we committed to in > >> http://tools.ietf.org/wg/martini/charters have us adopting > a working > >> group SOLUTION draft in January. We're not late yet, but it's the > >> 28th > >> of January in my time zone. If we are late, where late is > measured in > >> days, I can live with that, but if we are late, where late is > >> measured > >> in IETF meeting cycles, that's going to be a problem. > >> > >> Thanks, > >> > >> Spencer, as co-chair > >> > >> ----- Original Message ----- > >> From: "Eric Burger" > >> To: "Dean Willis" > >> Cc: > >> Sent: Thursday, January 28, 2010 12:32 PM > >> Subject: Re: [martini] Proposed work split: tackle > >> telephone-numberregistration first > >> > >> > >> > If you ask me (why can't I stay in retirement?), the E.164 > >> situation > >> is > >> > not only a simplification, but just about the only thing that is > >> sensible > >> > for MARTINI to work on. > >> > > >> > The E.164 situation is a clear, present, > industry-is-begging-for-a- > >> > solution problem. It is so pressing, the industry will tell us > >> (the > >> > IETF) to get stuffed and do something stupid if we cannot deliver > >> > something that is not at its core fundamentally broken. > >> > > >> > I do not think anyone can have an issue with mechanisms > >> that translate > >> a > >> > string of digits into an AOR that might cross domain boundaries. > >> This is > >> > the E.164 problem statement. > >> > > >> > If think everyone (with a brain) SHOULD have issues with a > >> mechanism > >> that > >> > magically mungs "sip:eburger@neustar.biz" into > >> "sip:5350@pbx.example.net " > >> > while at the same time www.neustar.biz is really a neustar.biz > >> domain. > >> > That really would be creating a parallel DNS, which, as > one of the > >> major > >> > DNS operators, would really, really be "less than ideal" and > >> have a > >> whole > >> > host of security and integrity issues. > >> > > >> > THEREFORE, I would propose that we split this work into > two phases: > >> > Phase 1: Deliver an E.164 solution, preferably in the next few > >> months, > >> > so the industry does not ignore the IETF. > >> > > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year > >> IETF > >> > cycle. This generic solution may or may not encompass > >> E.164 numbers. > >> As > >> > Doug Sauder points out, E.164 numbers and their > infrastructure are > >> > different. Thus a different E.164 registration model from > >> generic SIP > >> > URI provisioning models would neither be a burden on industry nor > >> create > >> > backwards-compatibility issues for the generic solution. > >> > > >> > Note that if we do not deliver Phase 1 in a very, very > >> timely manner, > >> the > >> > less-than-idea industry solution just might blow up the > >> possibility > >> for > >> > the generic solution, which would be considerably less > than ideal. > >> > > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > >> > > >> >> > >> >> We seem to have an urgent need for a near-term solution for > >> dealing > >> with > >> >> the subset of the MARTINI problem that, loosely defined, > >> covers the > >> >> "telephone number" problem. > >> >> > >> >> The typical scenario here is SIP trunking, wherein a SIP Service > >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a > >> customer's > >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch > >> of phone > >> >> numbers to the PBXes. This mapping is somewhat dynamic, > >> because the > >> >> PBXes usually have DHCP addresses, and don't have DNS entries > >> that > >> point > >> >> A records at the PBX in any sort of particularly useful way > >> (maybe > >> >> something like dhcp-10-1-2-3- example.com). > >> >> > >> >> So what we need is a way for a PBX, when it reboots (or perhaps > >> >> periodically) to say to the SSP "Here I Am; You may now send any > >> calls > >> >> for my assigned phone numbers to my current Contact." > >> >> > >> >> This is indeed a "registration" problem, but it isn't > >> necessarily a > >> >> "domain registration problem". The only reason domains get mixed > >> into > >> >> this scenario at all is that we sometimes encode telephone > >> numbers > >> as > >> >> the user parts of SIP URIs, and those SIP URIs have a > domain part > >> >> attached to them. > >> >> > >> >> More interestingly, this problem is a tiny subset of the whole > >> MARTINI > >> >> dynamic binding problem, and it potentially can be solved > >> much more > >> >> simply than the general problem. > >> >> > >> >> On today's Interim II call, Richard, Adam and I raised > the idea of > >> >> dividing our problem space, and taking on a near-term > milestone > >> for > >> >> delivering a MARTINI solution for registering contacts > to a proxy, > >> where > >> >> that proxy maps one or more telephone numbers to the contact. > >> >> > >> >> We certainly intend to go on and tackle the more general domain- > >> >> registration problem, but I (and I believe Adam and > >> Richard) believe > >> >> that we get a lot out of tackling the telephone-number > >> subset first. > >> >> > >> >> In particular, we believe that this approach solves many of the > >> domain > >> >> "responsibility" questions, simplifies the TLS keying/ > >> certification > >> >> model immensely, eliminates the cognitive overload of > >> using REGISTER > >> to > >> >> bind a "domain" to a Contact, "route authentication", > and a good > >> many > >> >> other open issues that plague our current drafts. > >> >> > >> >> > >> >> Open questions relating to this approach include: > >> >> > >> >> 1) Do we deal only with E.164 numbers, or do we need to > deal with > >> >> private-number "phone contexts"? > >> >> > >> >> 2) D owe need to explicitly encode the telephone numbers being > >> >> registered in the REGISTER request (either directly or through > >> some > >> sort > >> >> of regexp), or is it adequate to rely on provisioning of > >> the SSP and > >> PBX > >> >> (and any UAs) to statically bind the numbers to the PBX > identity, > >> and > >> >> then dynamically only register the PBX identity to the > >> PBX contact? > >> >> > >> >> 3) Can we "register" with a tel: URI as the "To" value? (this > >> seems > >> to > >> >> require extending RFC 3261)? Note that "tel:" can express > >> both E. 164 > >> >> numbers and private phone-contexts in one format. > >> >> > >> >> 4) What happens with GRUUs? > >> >> > >> >> I believe all of these issues are quite tractable, if > we accept > >> the > >> >> fundamental idea of splitting the phone-number problem > off from > >> the > >> more > >> >> general domain-registration, and recognize the possibility > >> that the > >> >> solutions to the two problem may reasonably be quite > >> different from > >> each > >> >> other. > >> >> > >> >> So, what do you people think? Is it worth trying to drink the > >> MARTINI > >> >> elephant one sip at a time, or are we going to treat the > >> whole thing > >> >> like a tequila shot and just slam it down? > >> >> > >> >> -- > >> >> Dean > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> martini mailing list > >> >> martini@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/martini > >> > > >> > _______________________________________________ > >> > martini mailing list > >> > martini@ietf.org > >> > https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > >> _______________________________________________ > >> martini mailing list > >> martini@ietf.org > >> https://www.ietf.org/mailman/listinfo/martini > >> > > > > ********************************* > > This message and any attachments (the "message") are confidential > > and intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if > altered, > > changed or falsified. > > If you are not the intended addressee of this message, > please cancel > > it immediately and inform the sender. > > ******************************** > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From xavier.marjou@gmail.com Fri Jan 29 13:40:15 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C5D3A67FD for ; Fri, 29 Jan 2010 13:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jByeIbvYxm5I for ; Fri, 29 Jan 2010 13:40:14 -0800 (PST) Received: from mail-qy0-f188.google.com (mail-qy0-f188.google.com [209.85.221.188]) by core3.amsl.com (Postfix) with ESMTP id 7C4213A6403 for ; Fri, 29 Jan 2010 13:40:14 -0800 (PST) Received: by qyk26 with SMTP id 26so1029605qyk.5 for ; Fri, 29 Jan 2010 13:40:34 -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; bh=KhHMwlBKC0VIw25SWwSh9rR/m46E02zMNkiliQHJZSA=; b=xNLgD4m7DF32+50ssktBz9lv8ez6ABIrAflX3nH3O8mF6CWx3KB2n+zs9l2puVnLOB cLZksHf1v7loK1vC3HMju3UCBfGk9V4BUe9+r7RJmCVCxqvBEWVR9mySfX7f8h17G+PV a9wL/ZSCl0Rqg+YlT0mv+cf2M5ICiJEbFV3a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UKZ0tUqSv5PYMJOpXsVJEZTj1HnGUSQuDDYg69KomE9dK/LBUOlyomziz/DB69E8Hz eqqdsveyIuKMyAkE3GA6cn59o1fOzwcyyjg4t4iUSFOZKxKtG9NNFVtzaLj+1VK1PiJD hZFJQDiM9AfihgkRVM4EIfBxTuX2xEWJHb6m4= MIME-Version: 1.0 Received: by 10.229.241.82 with SMTP id ld18mr343869qcb.60.1264801234439; Fri, 29 Jan 2010 13:40:34 -0800 (PST) In-Reply-To: <4B630F56.1020304@nostrum.com> References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> <4B630F56.1020304@nostrum.com> Date: Fri, 29 Jan 2010 22:40:34 +0100 Message-ID: <458913681001291340v150237fewf670f88005511f12@mail.gmail.com> From: Xavier Marjou To: Adam Roach , martini@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 21:40:15 -0000 Hi Adam, > Changing the semantics of REGISTER to indicate more than one human breaks > certain security (policy) assumptions at intermediaries. It may also cause > problems with Path, Service-Route, and connection re-use (that is, they may > not "just work", as previously claimed, due to changing security > properties). I don't agree the semantic is broken: In RFC3261, a REGISTER registers an AOR and its adress-of-contact. It is not said that the AOR has to be a single human. So examples of valid AOR could be: sip:bob@foo.com, sip:bob.and.carol@foo.com, sip:bob.family@foo.com, sip:bob.company@foo.com My 2 cents, Xavier From christer.holmberg@ericsson.com Fri Jan 29 14:53:32 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA12B3A688A for ; Fri, 29 Jan 2010 14:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.230, 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 kCinAvHoJW6q for ; Fri, 29 Jan 2010 14:53:32 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D25D93A63EC for ; Fri, 29 Jan 2010 14:53:31 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-1a-4b6367013737 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id D3.54.23735.107636B4; Fri, 29 Jan 2010 23:53:53 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.199]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 29 Jan 2010 23:53:53 +0100 From: Christer Holmberg To: Eric Burger , "bruno.chatras@orange-ftgroup.com" Date: Fri, 29 Jan 2010 23:53:52 +0100 Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: Acqg8Q9YQw08F3aqQLiUrveGPpzGTAAQjEUY Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 22:53:33 -0000 >More especially so given the industry today is 99.9% E.164 Do you assume all those E.164 numbers will be carried in a TEL-URI? That se= ems to be the assumption for the "short-term solution" people are talking a= bout... Regards, Christer= From drage@alcatel-lucent.com Fri Jan 29 16:08:33 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BCB3A67B3 for ; Fri, 29 Jan 2010 16:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333, 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 SUh5x-yd7Uwt for ; Fri, 29 Jan 2010 16:08:31 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B9FA23A679C for ; Fri, 29 Jan 2010 16:08:30 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o0U08pG1028935 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 30 Jan 2010 01:08:52 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 30 Jan 2010 01:08:51 +0100 From: "DRAGE, Keith (Keith)" To: Richard Shockey , "'Eric Burger'" , "bruno.chatras@orange-ftgroup.com" Date: Sat, 30 Jan 2010 01:08:49 +0100 Thread-Topic: [martini] Proposed work split:tackletelephone-numberregistration first Thread-Index: Acqg8SOnJoy7PGNpQpqpCyGEkpv8MgALpOlQAAGpFDAABmfKAA== Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <003c01caa126$693153b0$3b93fb10$@us> In-Reply-To: <003c01caa126$693153b0$3b93fb10$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:08:33 -0000 Exactly - that is what I understood too - so they all tend to be encumbered= by domain names. And lots of them use things like 4269@alcatel-lucent.com internally as well= if I understand correctly, which are neither fish nor fowl. So arguing that we need a solution for tel URIs because that is what is cur= rently supported is incorrect. regards Keith > -----Original Message----- > From: Richard Shockey [mailto:richard@shockey.us] > Sent: Friday, January 29, 2010 9:03 PM > To: DRAGE, Keith (Keith); 'Eric Burger'; > bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: RE: [martini] Proposed work > split:tackletelephone-numberregistration first > > The latter ... as far as I've able to determine > > -----Original Message----- > From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Friday, January 29, 2010 3:16 PM > To: Eric Burger; bruno.chatras@orange-ftgroup.com > Cc: martini@ietf.org > Subject: Re: [martini] Proposed work > split:tackletelephone-numberregistration first > > Is the market today 100% tel URIs or is it 100% telephone > numbers masquerading as SIP URIs? > > regards > > Keith > > > -----Original Message----- > > From: martini-bounces@ietf.org > > [mailto:martini-bounces@ietf.org] On Behalf Of Eric Burger > > Sent: Friday, January 29, 2010 2:41 PM > > To: bruno.chatras@orange-ftgroup.com > > Cc: martini@ietf.org > > Subject: Re: [martini] Proposed work > > split:tackletelephone-numberregistration first > > > > On the one hand, I agree we have to work on a general mechanism to > > enable the SP to provision IP PBXen as well as an efficient > way for IP > > PBXen to register endpoints to an SP. > > > > On the other hand, are you willing to wait 3-5 years for > the general > > mechanism? More especially so given the industry today is > 99.9% E.164 > > numbers and needs a solution last year? > > This is a serious question: if service providers are > saying, "This is > > going to be important, but we really do not need a solution in 3-5 > > years," then that informs our > > work: we can relax and engineer the perfect solution. > > However, almost all of the service providers I speak with say, "A > > solution to this problem is already a year late. If we do not see > > something soon [2-3 months] we are going to codify and deploy the > > (admittedly broken) REGISTER method that we are already > using, with or > > without the IETF. > > It would be nice if we could have a not-so-broken > mechanism, but the > > market has lost its patience." > > > > Again, doing the E.164-only solution today does not mean we > ignore the > > long-term problem. > > > > Does this work for you? > > > > On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: > > > > > Hi, Bruno, > > > > > > My apologies for not snapping when I saw your e-mail > address - I'm > > > currently chairing three working groups, and things are getting a > > > little blurry (MEDIACTRL *really* needs to finish soon!). > > > > > > Thanks for the input - it's helpful. > > > > > > Spencer > > > > > > ----- Original Message ----- From: > > > > > To: ; ; > > > > > >; > > > Cc: > > > Sent: Friday, January 29, 2010 7:39 AM > > > Subject: RE: [martini] Proposed work split:tackletelephone- > > > numberregistration first > > > > > > > > > Hi Spencer, > > > > > > I have seen you request on the sip-ops list where you noted that > > > MARTINI is not getting inputs from other operators (than > CableLabs). > > > I'm actually representing a fixed and mobile operator > > (France Telecom > > > - Orange) and as you can guess from my previous posts we > support a > > > REGISTER-based solution and believe that a solution > > restricted to Tel > > > URIs would be of limited interest. > > > > > > /BC > > > > > > > > > > > >> -----Message d'origine----- > > >> De : martini-bounces@ietf.org > > >> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins > > >> Envoy=E9 : jeudi 28 janvier 2010 22:59 =C0 : Brian Lindsay; Eric > > >> Burger; Dean Willis Cc : martini@ietf.org Objet : Re: [martini] > > >> Proposed work split:tackletelephone-numberregistration first > > >> > > >> Hi, Brian, > > >> > > >> Thanks for the quick feedback. I'm mostly asking if I'm reading > > >> where we are going correctly (I GOTTA get the draft minutes out > > >> from that call!). > > >> > > >> This is kind of twisty-little-passages-all-alike/different > > >> (for those of you that remember the "adventure" game in > the early > > >> 1980s), but I'm trying to follow the chain. Where I thought we > > >> were, was that we didn't have a coherent story for how we get a > > >> call from outside the service provider, to the service > provider, to > > >> the SIP-PBX, and I've heard a bunch of smart guys talk > for a long > > >> time on a number of occasions about how that might > work/not work, > > >> usually ending with "but if this was limited to E.164 numbers, a > > >> lot of these problems would go away". > > >> > > >> So I'm trying to laces comments from the call that I remember > > >> together, and see what the resulting tapestry looks like. > > >> > > >> Tell you what. I'll go work on draft minutes and stop typing > > >> e-mail, and we'll see if that works better :D > > >> > > >> Spencer > > >> > > >> ----- Original Message ----- > > >> From: "Brian Lindsay" > > >> To: "Spencer Dawkins" ; "Eric Burger" > > >> ; "Dean Willis" > > >> > > >> Cc: > > >> Sent: Thursday, January 28, 2010 3:48 PM > > >> Subject: RE: [martini] Proposed work split: > > >> tackletelephone-numberregistration first > > >> > > >> > > >> Hi Spencer, > > >> > > >> I am not sure if this is going down the path that the actual > > >> register request uses a Tel: URI. > > >> > > >> If so, I don't see why that needs to be the case. The REGISTER > > >> itself can still be done per Martini-Shaken with a SIP URI > > >> representing the SIP PBX. In fact, I am not sure too much has to > > >> change with Martini- Shaken unless you want to enforce > use of a Tel > > >> URI format for > > requests sent > > >> towards the SIP PBX. > > >> > > >> Thanks > > >> Brian > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: martini-bounces@ietf.org > [mailto:martini-bounces@ietf.org] On > > >> Behalf Of Spencer Dawkins > > >> Sent: Thursday, January 28, 2010 4:39 PM > > >> To: Eric Burger; Dean Willis > > >> Cc: martini@ietf.org > > >> Subject: Re: [martini] Proposed work split: > > >> tackletelephone-numberregistration first > > >> > > >> OK, this discussion continues to be lovely. Thanks again for > > >> listening to the people you're talking to ("plays well > with others" > > >> is under-appreciated, once we get out of primary school, but *I* > > >> appreciate > > >> it!) > > >> > > >> After reading this thread down through Eric's note below, > > I have a > > >> few > > >> requests, as co-chair. > > >> > > >> We're talking about E.164 numbers like we can easily > > identify them. > > >> My > > >> understanding from Tuesday's call was that people on the > > call thought > > >> the only way we could unambiguously know that we had an E.164 > > >> number was if we had a tel: URI. If people on this list want to > > >> challenge that assertion, this would be a great time to say so - > > >> please push back Real Soon Now. > > >> > > >> If that's true, we're talking about using Tel: URIs. Dean has > > >> asserted that this would require an update to 3261. I'm not a > > >> genius of 3261, but some of you guys are - could you point us to > > >> what you think needs to be updated? > > >> > > >> My quick read turned up this text in Section 4, page 17: > > >> > > >> Registration is another common operation in SIP. > > >> Registration is one > > >> way that the biloxi.com server can learn the current > location of > > >> Bob. > > >> Upon initialization, and at periodic intervals, Bob's > SIP phone > > >> sends > > >> REGISTER messages to a server in the biloxi.com domain > known as a > > >> SIP > > >> registrar. The REGISTER messages associate Bob's SIP > or SIPS URI > > >> (sip:bob@biloxi.com) with the machine into which he is > currently > > >> logged (conveyed as a SIP or SIPS URI in the Contact > > header field). > > >> > > >> Dean, Is this what you were thinking of? Are there other > > places that > > >> also need to change? > > >> > > >> As I read http://www.ietf.org/id/draft-peterson-rai- > > >> rfc3427bis-04.txt, > > >> Section 2.1, this change would have to go through > SIPCORE, because > > >> it's an update to 3261. If you know of obvious land mines that > > we would be > > >> walking into if we propose this change, please say so Real > > Soon Now. > > >> (One obvious land mine is that DISPATCH isn't meeting in > Anaheim, > > >> so the proposal would have to be DISPATCHed on the > mailing list in > > >> order to do something before IETF 78 - are there OTHERS?) > > >> > > >> Finally, if you believe that embracing tel: URIs is the > > wrong thing > > >> to > > >> do, please say so, Real Soon Now. > > >> > > >> The milestones that we committed to in > > >> http://tools.ietf.org/wg/martini/charters have us adopting > > a working > > >> group SOLUTION draft in January. We're not late yet, but > it's the > > >> 28th of January in my time zone. If we are late, where late is > > measured in > > >> days, I can live with that, but if we are late, where late is > > >> measured in IETF meeting cycles, that's going to be a problem. > > >> > > >> Thanks, > > >> > > >> Spencer, as co-chair > > >> > > >> ----- Original Message ----- > > >> From: "Eric Burger" > > >> To: "Dean Willis" > > >> Cc: > > >> Sent: Thursday, January 28, 2010 12:32 PM > > >> Subject: Re: [martini] Proposed work split: tackle > > >> telephone-numberregistration first > > >> > > >> > > >> > If you ask me (why can't I stay in retirement?), the E.164 > > >> situation > > >> is > > >> > not only a simplification, but just about the only > thing that is > > >> sensible > > >> > for MARTINI to work on. > > >> > > > >> > The E.164 situation is a clear, present, > > industry-is-begging-for-a- > > >> > solution problem. It is so pressing, the industry will tell us > > >> (the > > >> > IETF) to get stuffed and do something stupid if we > cannot deliver > > >> > something that is not at its core fundamentally broken. > > >> > > > >> > I do not think anyone can have an issue with mechanisms > > >> that translate > > >> a > > >> > string of digits into an AOR that might cross domain > boundaries. > > >> This is > > >> > the E.164 problem statement. > > >> > > > >> > If think everyone (with a brain) SHOULD have issues with a > > >> mechanism > > >> that > > >> > magically mungs "sip:eburger@neustar.biz" into > > >> "sip:5350@pbx.example.net " > > >> > while at the same time www.neustar.biz is really a neustar.biz > > >> domain. > > >> > That really would be creating a parallel DNS, which, as > > one of the > > >> major > > >> > DNS operators, would really, really be "less than ideal" and > > >> have a > > >> whole > > >> > host of security and integrity issues. > > >> > > > >> > THEREFORE, I would propose that we split this work into > > two phases: > > >> > Phase 1: Deliver an E.164 solution, preferably in > the next few > > >> months, > > >> > so the industry does not ignore the IETF. > > >> > > > >> > Phase 2: Deliver the generic solution in the normal, 3-5 year > > >> IETF > > >> > cycle. This generic solution may or may not encompass > > >> E.164 numbers. > > >> As > > >> > Doug Sauder points out, E.164 numbers and their > > infrastructure are > > >> > different. Thus a different E.164 registration model from > > >> generic SIP > > >> > URI provisioning models would neither be a burden on > industry nor > > >> create > > >> > backwards-compatibility issues for the generic solution. > > >> > > > >> > Note that if we do not deliver Phase 1 in a very, very > > >> timely manner, > > >> the > > >> > less-than-idea industry solution just might blow up the > > >> possibility > > >> for > > >> > the generic solution, which would be considerably less > > than ideal. > > >> > > > >> > On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: > > >> > > > >> >> > > >> >> We seem to have an urgent need for a near-term solution for > > >> dealing > > >> with > > >> >> the subset of the MARTINI problem that, loosely defined, > > >> covers the > > >> >> "telephone number" problem. > > >> >> > > >> >> The typical scenario here is SIP trunking, wherein a > SIP Service > > >> >> Provider (SSP) provides an ISDN-PRI like service over IP to a > > >> customer's > > >> >> PBX (or PBXes). In this model, the SSP maps a whole bunch > > >> of phone > > >> >> numbers to the PBXes. This mapping is somewhat dynamic, > > >> because the > > >> >> PBXes usually have DHCP addresses, and don't have DNS entries > > >> that > > >> point > > >> >> A records at the PBX in any sort of particularly useful way > > >> (maybe > > >> >> something like dhcp-10-1-2-3- example.com). > > >> >> > > >> >> So what we need is a way for a PBX, when it reboots > (or perhaps > > >> >> periodically) to say to the SSP "Here I Am; You may > now send any > > >> calls > > >> >> for my assigned phone numbers to my current Contact." > > >> >> > > >> >> This is indeed a "registration" problem, but it isn't > > >> necessarily a > > >> >> "domain registration problem". The only reason > domains get mixed > > >> into > > >> >> this scenario at all is that we sometimes encode telephone > > >> numbers > > >> as > > >> >> the user parts of SIP URIs, and those SIP URIs have a > > domain part > > >> >> attached to them. > > >> >> > > >> >> More interestingly, this problem is a tiny subset of the whole > > >> MARTINI > > >> >> dynamic binding problem, and it potentially can be solved > > >> much more > > >> >> simply than the general problem. > > >> >> > > >> >> On today's Interim II call, Richard, Adam and I raised > > the idea of > > >> >> dividing our problem space, and taking on a near-term > > milestone > > >> for > > >> >> delivering a MARTINI solution for registering contacts > > to a proxy, > > >> where > > >> >> that proxy maps one or more telephone numbers to the contact. > > >> >> > > >> >> We certainly intend to go on and tackle the more > general domain- > > >> >> registration problem, but I (and I believe Adam and > > >> Richard) believe > > >> >> that we get a lot out of tackling the telephone-number > > >> subset first. > > >> >> > > >> >> In particular, we believe that this approach solves > many of the > > >> domain > > >> >> "responsibility" questions, simplifies the TLS keying/ > > >> certification > > >> >> model immensely, eliminates the cognitive overload of > > >> using REGISTER > > >> to > > >> >> bind a "domain" to a Contact, "route authentication", > > and a good > > >> many > > >> >> other open issues that plague our current drafts. > > >> >> > > >> >> > > >> >> Open questions relating to this approach include: > > >> >> > > >> >> 1) Do we deal only with E.164 numbers, or do we need to > > deal with > > >> >> private-number "phone contexts"? > > >> >> > > >> >> 2) D owe need to explicitly encode the telephone > numbers being > > >> >> registered in the REGISTER request (either directly or through > > >> some > > >> sort > > >> >> of regexp), or is it adequate to rely on provisioning of > > >> the SSP and > > >> PBX > > >> >> (and any UAs) to statically bind the numbers to the PBX > > identity, > > >> and > > >> >> then dynamically only register the PBX identity to the > > >> PBX contact? > > >> >> > > >> >> 3) Can we "register" with a tel: URI as the "To" value? (this > > >> seems > > >> to > > >> >> require extending RFC 3261)? Note that "tel:" can express > > >> both E. 164 > > >> >> numbers and private phone-contexts in one format. > > >> >> > > >> >> 4) What happens with GRUUs? > > >> >> > > >> >> I believe all of these issues are quite tractable, if > > we accept > > >> the > > >> >> fundamental idea of splitting the phone-number problem > > off from > > >> the > > >> more > > >> >> general domain-registration, and recognize the possibility > > >> that the > > >> >> solutions to the two problem may reasonably be quite > > >> different from > > >> each > > >> >> other. > > >> >> > > >> >> So, what do you people think? Is it worth trying to drink the > > >> MARTINI > > >> >> elephant one sip at a time, or are we going to treat the > > >> whole thing > > >> >> like a tequila shot and just slam it down? > > >> >> > > >> >> -- > > >> >> Dean > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> martini mailing list > > >> >> martini@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/martini > > >> > > > >> > _______________________________________________ > > >> > martini mailing list > > >> > martini@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/martini > > >> > > >> _______________________________________________ > > >> martini mailing list > > >> martini@ietf.org > > >> https://www.ietf.org/mailman/listinfo/martini > > >> > > >> _______________________________________________ > > >> martini mailing list > > >> martini@ietf.org > > >> https://www.ietf.org/mailman/listinfo/martini > > >> > > > > > > ********************************* > > > This message and any attachments (the "message") are confidential > > > and intended solely for the addressees. > > > Any unauthorised use or dissemination is prohibited. > > > Messages are susceptible to alteration. > > > France Telecom Group shall not be liable for the message if > > altered, > > > changed or falsified. > > > If you are not the intended addressee of this message, > > please cancel > > > it immediately and inform the sender. > > > ******************************** > > > > > > > _______________________________________________ > > martini mailing list > > martini@ietf.org > > https://www.ietf.org/mailman/listinfo/martini > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > > From eburger@standardstrack.com Fri Jan 29 16:12:42 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744E43A67B3 for ; Fri, 29 Jan 2010 16:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ROHPVPfVRJs for ; Fri, 29 Jan 2010 16:12:40 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 34F6F3A679C for ; Fri, 29 Jan 2010 16:12:40 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.178]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nb0xM-0007rD-Mu; Fri, 29 Jan 2010 16:12:57 -0800 Message-Id: From: Eric Burger To: In-Reply-To: <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 19:13:00 -0500 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com> <10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr> <84635F3C80D944849BB87F5AA9E093EA@china.huawei.com> <2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> 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: Cc: martini@ietf.org Subject: Re: [martini] Proposed work split:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:12:42 -0000 Sorry, but the AVERAGE time to take something from ID-0 to RFC is 48 =20 months. E.164-only has a chance because it has been worked on for over two =20 years and there was virtually unanimous buy-in at the DRINKS BOF =20 (which became the MARTINI work group) that if the problem domain was =20 restricted to E.164 numbers, then the proposed approach would be =20 acceptable. Any generic approach will not have such support and will take the =20 normal IETF discussion period of 3-5 years. Longer if it involves INFO :-) [Inside joke for old SIP folks] On Jan 29, 2010, at 11:28 AM, = wrote: > Of course we do not need a solution in 3-5 years. However I hardly =20 > believe that a generic solution would require 3-5 years if the E.164-=20= > only solutions requires only 2 or 3 months. > > I also understand that doing the E.164-only solution today does not =20= > mean we ignore the long-term problem. However I still think that an =20= > E.164-only solution has almost no value compared to the current 3GPP/=20= > ETSI solution, especially if the long-term solution significantly =20 > differs from the E.164-only solution. I'm not convinced that the =20 > issues identified with the 3GPP/ETSI/IMS solution prevent =20 > implementing it even outside the context of the IMS. I'm aware of a =20= > number of PBX on the market than can already accept an inbound =20 > INVITE request with a Request-URI containing either the registered =20 > contact or one of the implictly or explictly registered AoRs. > > BC > >> -----Message d'origine----- >> De : Eric Burger [mailto:eburger@standardstrack.com] >> Envoy=E9 : vendredi 29 janvier 2010 15:41 >> =C0 : CHATRAS Bruno RD-CORE-ISS >> Cc : martini@ietf.org >> Objet : Re: [martini] Proposed work >> split:tackletelephone-numberregistration first >> >> On the one hand, I agree we have to work on a general >> mechanism to enable the SP to provision IP PBXen as well as >> an efficient way for IP PBXen to register endpoints to an SP. >> >> On the other hand, are you willing to wait 3-5 years for the >> general mechanism? More especially so given the industry >> today is 99.9% E.164 numbers and needs a solution last year? >> This is a serious question: if service providers are saying, >> "This is going to be important, but we really do not need a >> solution in 3-5 years," then that informs our >> work: we can relax and engineer the perfect solution. >> However, almost all of the service providers I speak with >> say, "A solution to this problem is already a year late. If >> we do not see something soon [2-3 months] we are going to >> codify and deploy the (admittedly broken) REGISTER method >> that we are already using, with or without the IETF. >> It would be nice if we could have a not-so-broken mechanism, >> but the market has lost its patience." >> >> Again, doing the E.164-only solution today does not mean we >> ignore the long-term problem. >> >> Does this work for you? >> >> On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: >> >>> Hi, Bruno, >>> >>> My apologies for not snapping when I saw your e-mail address - I'm >>> currently chairing three working groups, and things are getting a >>> little blurry (MEDIACTRL *really* needs to finish soon!). >>> >>> Thanks for the input - it's helpful. >>> >>> Spencer >>> >>> ----- Original Message ----- From: >> >>> To: ; ; >>> >>> ; >>> Cc: >>> Sent: Friday, January 29, 2010 7:39 AM >>> Subject: RE: [martini] Proposed work split:tackletelephone- >>> numberregistration first >>> >>> >>> Hi Spencer, >>> >>> I have seen you request on the sip-ops list where you noted that >>> MARTINI is not getting inputs from other operators (than CableLabs). >>> I'm actually representing a fixed and mobile operator >> (France Telecom >>> - Orange) and as you can guess from my previous posts we support a >>> REGISTER-based solution and believe that a solution >> restricted to Tel >>> URIs would be of limited interest. >>> >>> /BC >>> >>> >>> >>>> -----Message d'origine----- >>>> De : martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins >>>> Envoy=E9 : jeudi 28 janvier 2010 22:59 >>>> =C0 : Brian Lindsay; Eric Burger; Dean Willis >>>> Cc : martini@ietf.org >>>> Objet : Re: [martini] Proposed work >>>> split:tackletelephone-numberregistration first >>>> >>>> Hi, Brian, >>>> >>>> Thanks for the quick feedback. I'm mostly asking if I'm >>>> reading where we are going correctly (I GOTTA get the draft >>>> minutes out from that call!). >>>> >>>> This is kind of twisty-little-passages-all-alike/different >>>> (for those of you that remember the "adventure" game in the >>>> early 1980s), but I'm trying to follow the chain. Where I >>>> thought we were, was that we didn't have a coherent story for >>>> how we get a call from outside the service provider, to the >>>> service provider, to the SIP-PBX, and I've heard a bunch of >>>> smart guys talk for a long time on a number of occasions >>>> about how that might work/not work, usually ending with "but >>>> if this was limited to E.164 numbers, a lot of these problems >>>> would go away". >>>> >>>> So I'm trying to laces comments from the call that I remember >>>> together, and see what the resulting tapestry looks like. >>>> >>>> Tell you what. I'll go work on draft minutes and stop typing >>>> e-mail, and we'll see if that works better :D >>>> >>>> Spencer >>>> >>>> ----- Original Message ----- >>>> From: "Brian Lindsay" >>>> To: "Spencer Dawkins" ; "Eric Burger" >>>> ; "Dean Willis" >>>> >>>> Cc: >>>> Sent: Thursday, January 28, 2010 3:48 PM >>>> Subject: RE: [martini] Proposed work split: >>>> tackletelephone-numberregistration first >>>> >>>> >>>> Hi Spencer, >>>> >>>> I am not sure if this is going down the path that the >>>> actual register >>>> request uses a Tel: URI. >>>> >>>> If so, I don't see why that needs to be the case. The >>>> REGISTER itself >>>> can still be done per Martini-Shaken with a SIP URI >>>> representing the SIP >>>> PBX. In fact, I am not sure too much has to change with Martini- >>>> Shaken >>>> unless you want to enforce use of a Tel URI format for >> requests sent >>>> towards the SIP PBX. >>>> >>>> Thanks >>>> Brian >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>>> Behalf Of Spencer Dawkins >>>> Sent: Thursday, January 28, 2010 4:39 PM >>>> To: Eric Burger; Dean Willis >>>> Cc: martini@ietf.org >>>> Subject: Re: [martini] Proposed work split: >>>> tackletelephone-numberregistration first >>>> >>>> OK, this discussion continues to be lovely. Thanks again for >>>> listening >>>> to the people you're talking to ("plays well with others" is >>>> under-appreciated, once we get out of primary school, but *I* >>>> appreciate >>>> it!) >>>> >>>> After reading this thread down through Eric's note below, >> I have a >>>> few >>>> requests, as co-chair. >>>> >>>> We're talking about E.164 numbers like we can easily >> identify them. >>>> My >>>> understanding from Tuesday's call was that people on the >> call thought >>>> the only way we could unambiguously know that we had an E.164 >>>> number was >>>> if we had a tel: URI. If people on this list want to challenge that >>>> assertion, this would be a great time to say so - please push >>>> back Real >>>> Soon Now. >>>> >>>> If that's true, we're talking about using Tel: URIs. Dean has >>>> asserted >>>> that this would require an update to 3261. I'm not a genius >>>> of 3261, but >>>> some of you guys are - could you point us to what you think >>>> needs to be >>>> updated? >>>> >>>> My quick read turned up this text in Section 4, page 17: >>>> >>>> Registration is another common operation in SIP. >>>> Registration is one >>>> way that the biloxi.com server can learn the current >>>> location of Bob. >>>> Upon initialization, and at periodic intervals, Bob's SIP >>>> phone sends >>>> REGISTER messages to a server in the biloxi.com domain >>>> known as a SIP >>>> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >>>> (sip:bob@biloxi.com) with the machine into which he is currently >>>> logged (conveyed as a SIP or SIPS URI in the Contact >> header field). >>>> >>>> Dean, Is this what you were thinking of? Are there other >> places that >>>> also need to change? >>>> >>>> As I read http://www.ietf.org/id/draft-peterson-rai- >>>> rfc3427bis-04.txt, >>>> Section 2.1, this change would have to go through SIPCORE, >>>> because it's >>>> an update to 3261. If you know of obvious land mines that >> we would be >>>> walking into if we propose this change, please say so Real >> Soon Now. >>>> (One obvious land mine is that DISPATCH isn't meeting in >>>> Anaheim, so the >>>> proposal would have to be DISPATCHed on the mailing list in >>>> order to do >>>> something before IETF 78 - are there OTHERS?) >>>> >>>> Finally, if you believe that embracing tel: URIs is the >> wrong thing >>>> to >>>> do, please say so, Real Soon Now. >>>> >>>> The milestones that we committed to in >>>> http://tools.ietf.org/wg/martini/charters have us adopting >> a working >>>> group SOLUTION draft in January. We're not late yet, but it's the >>>> 28th >>>> of January in my time zone. If we are late, where late is >> measured in >>>> days, I can live with that, but if we are late, where late is >>>> measured >>>> in IETF meeting cycles, that's going to be a problem. >>>> >>>> Thanks, >>>> >>>> Spencer, as co-chair >>>> >>>> ----- Original Message ----- >>>> From: "Eric Burger" >>>> To: "Dean Willis" >>>> Cc: >>>> Sent: Thursday, January 28, 2010 12:32 PM >>>> Subject: Re: [martini] Proposed work split: tackle >>>> telephone-numberregistration first >>>> >>>> >>>>> If you ask me (why can't I stay in retirement?), the E.164 >>>> situation >>>> is >>>>> not only a simplification, but just about the only thing that is >>>> sensible >>>>> for MARTINI to work on. >>>>> >>>>> The E.164 situation is a clear, present, >> industry-is-begging-for-a- >>>>> solution problem. It is so pressing, the industry will tell us >>>> (the >>>>> IETF) to get stuffed and do something stupid if we cannot deliver >>>>> something that is not at its core fundamentally broken. >>>>> >>>>> I do not think anyone can have an issue with mechanisms >>>> that translate >>>> a >>>>> string of digits into an AOR that might cross domain boundaries. >>>> This is >>>>> the E.164 problem statement. >>>>> >>>>> If think everyone (with a brain) SHOULD have issues with a >>>> mechanism >>>> that >>>>> magically mungs "sip:eburger@neustar.biz" into >>>> "sip:5350@pbx.example.net " >>>>> while at the same time www.neustar.biz is really a neustar.biz >>>> domain. >>>>> That really would be creating a parallel DNS, which, as >> one of the >>>> major >>>>> DNS operators, would really, really be "less than ideal" and >>>> have a >>>> whole >>>>> host of security and integrity issues. >>>>> >>>>> THEREFORE, I would propose that we split this work into >> two phases: >>>>> Phase 1: Deliver an E.164 solution, preferably in the next few >>>> months, >>>>> so the industry does not ignore the IETF. >>>>> >>>>> Phase 2: Deliver the generic solution in the normal, 3-5 year >>>> IETF >>>>> cycle. This generic solution may or may not encompass >>>> E.164 numbers. >>>> As >>>>> Doug Sauder points out, E.164 numbers and their >> infrastructure are >>>>> different. Thus a different E.164 registration model from >>>> generic SIP >>>>> URI provisioning models would neither be a burden on industry nor >>>> create >>>>> backwards-compatibility issues for the generic solution. >>>>> >>>>> Note that if we do not deliver Phase 1 in a very, very >>>> timely manner, >>>> the >>>>> less-than-idea industry solution just might blow up the >>>> possibility >>>> for >>>>> the generic solution, which would be considerably less >> than ideal. >>>>> >>>>> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >>>>> >>>>>> >>>>>> We seem to have an urgent need for a near-term solution for >>>> dealing >>>> with >>>>>> the subset of the MARTINI problem that, loosely defined, >>>> covers the >>>>>> "telephone number" problem. >>>>>> >>>>>> The typical scenario here is SIP trunking, wherein a SIP Service >>>>>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>>> customer's >>>>>> PBX (or PBXes). In this model, the SSP maps a whole bunch >>>> of phone >>>>>> numbers to the PBXes. This mapping is somewhat dynamic, >>>> because the >>>>>> PBXes usually have DHCP addresses, and don't have DNS entries >>>> that >>>> point >>>>>> A records at the PBX in any sort of particularly useful way >>>> (maybe >>>>>> something like dhcp-10-1-2-3- example.com). >>>>>> >>>>>> So what we need is a way for a PBX, when it reboots (or perhaps >>>>>> periodically) to say to the SSP "Here I Am; You may now send any >>>> calls >>>>>> for my assigned phone numbers to my current Contact." >>>>>> >>>>>> This is indeed a "registration" problem, but it isn't >>>> necessarily a >>>>>> "domain registration problem". The only reason domains get mixed >>>> into >>>>>> this scenario at all is that we sometimes encode telephone >>>> numbers >>>> as >>>>>> the user parts of SIP URIs, and those SIP URIs have a >> domain part >>>>>> attached to them. >>>>>> >>>>>> More interestingly, this problem is a tiny subset of the whole >>>> MARTINI >>>>>> dynamic binding problem, and it potentially can be solved >>>> much more >>>>>> simply than the general problem. >>>>>> >>>>>> On today's Interim II call, Richard, Adam and I raised >> the idea of >>>>>> dividing our problem space, and taking on a near-term >> milestone >>>> for >>>>>> delivering a MARTINI solution for registering contacts >> to a proxy, >>>> where >>>>>> that proxy maps one or more telephone numbers to the contact. >>>>>> >>>>>> We certainly intend to go on and tackle the more general domain- >>>>>> registration problem, but I (and I believe Adam and >>>> Richard) believe >>>>>> that we get a lot out of tackling the telephone-number >>>> subset first. >>>>>> >>>>>> In particular, we believe that this approach solves many of the >>>> domain >>>>>> "responsibility" questions, simplifies the TLS keying/ >>>> certification >>>>>> model immensely, eliminates the cognitive overload of >>>> using REGISTER >>>> to >>>>>> bind a "domain" to a Contact, "route authentication", >> and a good >>>> many >>>>>> other open issues that plague our current drafts. >>>>>> >>>>>> >>>>>> Open questions relating to this approach include: >>>>>> >>>>>> 1) Do we deal only with E.164 numbers, or do we need to >> deal with >>>>>> private-number "phone contexts"? >>>>>> >>>>>> 2) D owe need to explicitly encode the telephone numbers being >>>>>> registered in the REGISTER request (either directly or through >>>> some >>>> sort >>>>>> of regexp), or is it adequate to rely on provisioning of >>>> the SSP and >>>> PBX >>>>>> (and any UAs) to statically bind the numbers to the PBX >> identity, >>>> and >>>>>> then dynamically only register the PBX identity to the >>>> PBX contact? >>>>>> >>>>>> 3) Can we "register" with a tel: URI as the "To" value? (this >>>> seems >>>> to >>>>>> require extending RFC 3261)? Note that "tel:" can express >>>> both E. 164 >>>>>> numbers and private phone-contexts in one format. >>>>>> >>>>>> 4) What happens with GRUUs? >>>>>> >>>>>> I believe all of these issues are quite tractable, if >> we accept >>>> the >>>>>> fundamental idea of splitting the phone-number problem >> off from >>>> the >>>> more >>>>>> general domain-registration, and recognize the possibility >>>> that the >>>>>> solutions to the two problem may reasonably be quite >>>> different from >>>> each >>>>>> other. >>>>>> >>>>>> So, what do you people think? Is it worth trying to drink the >>>> MARTINI >>>>>> elephant one sip at a time, or are we going to treat the >>>> whole thing >>>>>> like a tequila shot and just slam it down? >>>>>> >>>>>> -- >>>>>> Dean >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> martini mailing list >>>>>> martini@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>> >>> ********************************* >>> This message and any attachments (the "message") are confidential >>> and intended solely for the addressees. >>> Any unauthorised use or dissemination is prohibited. >>> Messages are susceptible to alteration. >>> France Telecom Group shall not be liable for the message if >> altered, >>> changed or falsified. >>> If you are not the intended addressee of this message, >> please cancel >>> it immediately and inform the sender. >>> ******************************** >>> >> >> > > ********************************* > This message and any attachments (the "message") are confidential =20 > and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, =20= > changed or falsified. > If you are not the intended addressee of this message, please cancel =20= > it immediately and inform the sender. > ******************************** > From spencer@wonderhamster.org Fri Jan 29 16:36:25 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564983A6978 for ; Fri, 29 Jan 2010 16:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, SARE_RMML_Stock10=0.13, STOX_REPLY_TYPE=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 aj2lG26psDCE for ; Fri, 29 Jan 2010 16:36:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 3F2E43A694F for ; Fri, 29 Jan 2010 16:36:23 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M9sJc-1NUNV03b6u-00B3Ru; Fri, 29 Jan 2010 19:36:41 -0500 Message-ID: From: "Spencer Dawkins" To: "Eric Burger" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com><10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr><84635F3C80D944849BB87F5AA9E093EA@china.huawei.com><2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> Date: Fri, 29 Jan 2010 18:36:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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: V01U2FsdGVkX18LwmgskhiJLKAX3r7Uhl0y+YWRUsnWd/bthLy hsngR+Yg/lVCALgtG2h/1u8F/POBuOvCPASUvgCQ9PRnp2AuJS r+gIwfoHCXa/wmtu/nbfi7URKJJdI/jgWvevHYuO9s= Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:36:25 -0000 Hi, Eric, A couple of things: - MARTINI came from DREGS (DRINKS is the OTHER alcohol-related working group in RAI) - just in case anyone might be trying to trace the DRINKS-MARTINI link... - it seems to me that we're leaping from "E.164 numbers" - and I agree that DREGS and about a million other conversations keep telling us "E.164 numbers would be easier, and are the only things that matter, anyway" - to tel: URIs, which have only been under serious consideration for a few days. We're only fascinated with tel: URIs because tel: URIs can be unambiguously identified as globally unique, and we haven't come up with any other way of doing that. If we defined a new option tag that meant "globally unique E.164 number" for SIP URIs, would that give us what we need, without moving to tel: URIs? Thanks, Spencer ----- Original Message ----- From: "Eric Burger" To: Cc: Sent: Friday, January 29, 2010 6:13 PM Subject: Re: [martini] Proposed worksplit:tackletelephone-numberregistration first Sorry, but the AVERAGE time to take something from ID-0 to RFC is 48 months. E.164-only has a chance because it has been worked on for over two years and there was virtually unanimous buy-in at the DRINKS BOF (which became the MARTINI work group) that if the problem domain was restricted to E.164 numbers, then the proposed approach would be acceptable. Any generic approach will not have such support and will take the normal IETF discussion period of 3-5 years. Longer if it involves INFO :-) [Inside joke for old SIP folks] On Jan 29, 2010, at 11:28 AM, wrote: > Of course we do not need a solution in 3-5 years. However I hardly > believe that a generic solution would require 3-5 years if the E.164- only > solutions requires only 2 or 3 months. > > I also understand that doing the E.164-only solution today does not mean > we ignore the long-term problem. However I still think that an E.164-only > solution has almost no value compared to the current 3GPP/ ETSI solution, > especially if the long-term solution significantly differs from the > E.164-only solution. I'm not convinced that the issues identified with > the 3GPP/ETSI/IMS solution prevent implementing it even outside the > context of the IMS. I'm aware of a number of PBX on the market than can > already accept an inbound INVITE request with a Request-URI containing > either the registered contact or one of the implictly or explictly > registered AoRs. > > BC > >> -----Message d'origine----- >> De : Eric Burger [mailto:eburger@standardstrack.com] >> Envoyé : vendredi 29 janvier 2010 15:41 >> À : CHATRAS Bruno RD-CORE-ISS >> Cc : martini@ietf.org >> Objet : Re: [martini] Proposed work >> split:tackletelephone-numberregistration first >> >> On the one hand, I agree we have to work on a general >> mechanism to enable the SP to provision IP PBXen as well as >> an efficient way for IP PBXen to register endpoints to an SP. >> >> On the other hand, are you willing to wait 3-5 years for the >> general mechanism? More especially so given the industry >> today is 99.9% E.164 numbers and needs a solution last year? >> This is a serious question: if service providers are saying, >> "This is going to be important, but we really do not need a >> solution in 3-5 years," then that informs our >> work: we can relax and engineer the perfect solution. >> However, almost all of the service providers I speak with >> say, "A solution to this problem is already a year late. If >> we do not see something soon [2-3 months] we are going to >> codify and deploy the (admittedly broken) REGISTER method >> that we are already using, with or without the IETF. >> It would be nice if we could have a not-so-broken mechanism, >> but the market has lost its patience." >> >> Again, doing the E.164-only solution today does not mean we >> ignore the long-term problem. >> >> Does this work for you? >> >> On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: >> >>> Hi, Bruno, >>> >>> My apologies for not snapping when I saw your e-mail address - I'm >>> currently chairing three working groups, and things are getting a >>> little blurry (MEDIACTRL *really* needs to finish soon!). >>> >>> Thanks for the input - it's helpful. >>> >>> Spencer >>> >>> ----- Original Message ----- From: >> >>> To: ; ; >>> >>> ; >>> Cc: >>> Sent: Friday, January 29, 2010 7:39 AM >>> Subject: RE: [martini] Proposed work split:tackletelephone- >>> numberregistration first >>> >>> >>> Hi Spencer, >>> >>> I have seen you request on the sip-ops list where you noted that >>> MARTINI is not getting inputs from other operators (than CableLabs). >>> I'm actually representing a fixed and mobile operator >> (France Telecom >>> - Orange) and as you can guess from my previous posts we support a >>> REGISTER-based solution and believe that a solution >> restricted to Tel >>> URIs would be of limited interest. >>> >>> /BC >>> >>> >>> >>>> -----Message d'origine----- >>>> De : martini-bounces@ietf.org >>>> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins >>>> Envoyé : jeudi 28 janvier 2010 22:59 >>>> À : Brian Lindsay; Eric Burger; Dean Willis >>>> Cc : martini@ietf.org >>>> Objet : Re: [martini] Proposed work >>>> split:tackletelephone-numberregistration first >>>> >>>> Hi, Brian, >>>> >>>> Thanks for the quick feedback. I'm mostly asking if I'm >>>> reading where we are going correctly (I GOTTA get the draft >>>> minutes out from that call!). >>>> >>>> This is kind of twisty-little-passages-all-alike/different >>>> (for those of you that remember the "adventure" game in the >>>> early 1980s), but I'm trying to follow the chain. Where I >>>> thought we were, was that we didn't have a coherent story for >>>> how we get a call from outside the service provider, to the >>>> service provider, to the SIP-PBX, and I've heard a bunch of >>>> smart guys talk for a long time on a number of occasions >>>> about how that might work/not work, usually ending with "but >>>> if this was limited to E.164 numbers, a lot of these problems >>>> would go away". >>>> >>>> So I'm trying to laces comments from the call that I remember >>>> together, and see what the resulting tapestry looks like. >>>> >>>> Tell you what. I'll go work on draft minutes and stop typing >>>> e-mail, and we'll see if that works better :D >>>> >>>> Spencer >>>> >>>> ----- Original Message ----- >>>> From: "Brian Lindsay" >>>> To: "Spencer Dawkins" ; "Eric Burger" >>>> ; "Dean Willis" >>>> >>>> Cc: >>>> Sent: Thursday, January 28, 2010 3:48 PM >>>> Subject: RE: [martini] Proposed work split: >>>> tackletelephone-numberregistration first >>>> >>>> >>>> Hi Spencer, >>>> >>>> I am not sure if this is going down the path that the >>>> actual register >>>> request uses a Tel: URI. >>>> >>>> If so, I don't see why that needs to be the case. The >>>> REGISTER itself >>>> can still be done per Martini-Shaken with a SIP URI >>>> representing the SIP >>>> PBX. In fact, I am not sure too much has to change with Martini- >>>> Shaken >>>> unless you want to enforce use of a Tel URI format for >> requests sent >>>> towards the SIP PBX. >>>> >>>> Thanks >>>> Brian >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On >>>> Behalf Of Spencer Dawkins >>>> Sent: Thursday, January 28, 2010 4:39 PM >>>> To: Eric Burger; Dean Willis >>>> Cc: martini@ietf.org >>>> Subject: Re: [martini] Proposed work split: >>>> tackletelephone-numberregistration first >>>> >>>> OK, this discussion continues to be lovely. Thanks again for >>>> listening >>>> to the people you're talking to ("plays well with others" is >>>> under-appreciated, once we get out of primary school, but *I* >>>> appreciate >>>> it!) >>>> >>>> After reading this thread down through Eric's note below, >> I have a >>>> few >>>> requests, as co-chair. >>>> >>>> We're talking about E.164 numbers like we can easily >> identify them. >>>> My >>>> understanding from Tuesday's call was that people on the >> call thought >>>> the only way we could unambiguously know that we had an E.164 >>>> number was >>>> if we had a tel: URI. If people on this list want to challenge that >>>> assertion, this would be a great time to say so - please push >>>> back Real >>>> Soon Now. >>>> >>>> If that's true, we're talking about using Tel: URIs. Dean has >>>> asserted >>>> that this would require an update to 3261. I'm not a genius >>>> of 3261, but >>>> some of you guys are - could you point us to what you think >>>> needs to be >>>> updated? >>>> >>>> My quick read turned up this text in Section 4, page 17: >>>> >>>> Registration is another common operation in SIP. >>>> Registration is one >>>> way that the biloxi.com server can learn the current >>>> location of Bob. >>>> Upon initialization, and at periodic intervals, Bob's SIP >>>> phone sends >>>> REGISTER messages to a server in the biloxi.com domain >>>> known as a SIP >>>> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >>>> (sip:bob@biloxi.com) with the machine into which he is currently >>>> logged (conveyed as a SIP or SIPS URI in the Contact >> header field). >>>> >>>> Dean, Is this what you were thinking of? Are there other >> places that >>>> also need to change? >>>> >>>> As I read http://www.ietf.org/id/draft-peterson-rai- >>>> rfc3427bis-04.txt, >>>> Section 2.1, this change would have to go through SIPCORE, >>>> because it's >>>> an update to 3261. If you know of obvious land mines that >> we would be >>>> walking into if we propose this change, please say so Real >> Soon Now. >>>> (One obvious land mine is that DISPATCH isn't meeting in >>>> Anaheim, so the >>>> proposal would have to be DISPATCHed on the mailing list in >>>> order to do >>>> something before IETF 78 - are there OTHERS?) >>>> >>>> Finally, if you believe that embracing tel: URIs is the >> wrong thing >>>> to >>>> do, please say so, Real Soon Now. >>>> >>>> The milestones that we committed to in >>>> http://tools.ietf.org/wg/martini/charters have us adopting >> a working >>>> group SOLUTION draft in January. We're not late yet, but it's the >>>> 28th >>>> of January in my time zone. If we are late, where late is >> measured in >>>> days, I can live with that, but if we are late, where late is >>>> measured >>>> in IETF meeting cycles, that's going to be a problem. >>>> >>>> Thanks, >>>> >>>> Spencer, as co-chair >>>> >>>> ----- Original Message ----- >>>> From: "Eric Burger" >>>> To: "Dean Willis" >>>> Cc: >>>> Sent: Thursday, January 28, 2010 12:32 PM >>>> Subject: Re: [martini] Proposed work split: tackle >>>> telephone-numberregistration first >>>> >>>> >>>>> If you ask me (why can't I stay in retirement?), the E.164 >>>> situation >>>> is >>>>> not only a simplification, but just about the only thing that is >>>> sensible >>>>> for MARTINI to work on. >>>>> >>>>> The E.164 situation is a clear, present, >> industry-is-begging-for-a- >>>>> solution problem. It is so pressing, the industry will tell us >>>> (the >>>>> IETF) to get stuffed and do something stupid if we cannot deliver >>>>> something that is not at its core fundamentally broken. >>>>> >>>>> I do not think anyone can have an issue with mechanisms >>>> that translate >>>> a >>>>> string of digits into an AOR that might cross domain boundaries. >>>> This is >>>>> the E.164 problem statement. >>>>> >>>>> If think everyone (with a brain) SHOULD have issues with a >>>> mechanism >>>> that >>>>> magically mungs "sip:eburger@neustar.biz" into >>>> "sip:5350@pbx.example.net " >>>>> while at the same time www.neustar.biz is really a neustar.biz >>>> domain. >>>>> That really would be creating a parallel DNS, which, as >> one of the >>>> major >>>>> DNS operators, would really, really be "less than ideal" and >>>> have a >>>> whole >>>>> host of security and integrity issues. >>>>> >>>>> THEREFORE, I would propose that we split this work into >> two phases: >>>>> Phase 1: Deliver an E.164 solution, preferably in the next few >>>> months, >>>>> so the industry does not ignore the IETF. >>>>> >>>>> Phase 2: Deliver the generic solution in the normal, 3-5 year >>>> IETF >>>>> cycle. This generic solution may or may not encompass >>>> E.164 numbers. >>>> As >>>>> Doug Sauder points out, E.164 numbers and their >> infrastructure are >>>>> different. Thus a different E.164 registration model from >>>> generic SIP >>>>> URI provisioning models would neither be a burden on industry nor >>>> create >>>>> backwards-compatibility issues for the generic solution. >>>>> >>>>> Note that if we do not deliver Phase 1 in a very, very >>>> timely manner, >>>> the >>>>> less-than-idea industry solution just might blow up the >>>> possibility >>>> for >>>>> the generic solution, which would be considerably less >> than ideal. >>>>> >>>>> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >>>>> >>>>>> >>>>>> We seem to have an urgent need for a near-term solution for >>>> dealing >>>> with >>>>>> the subset of the MARTINI problem that, loosely defined, >>>> covers the >>>>>> "telephone number" problem. >>>>>> >>>>>> The typical scenario here is SIP trunking, wherein a SIP Service >>>>>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>>> customer's >>>>>> PBX (or PBXes). In this model, the SSP maps a whole bunch >>>> of phone >>>>>> numbers to the PBXes. This mapping is somewhat dynamic, >>>> because the >>>>>> PBXes usually have DHCP addresses, and don't have DNS entries >>>> that >>>> point >>>>>> A records at the PBX in any sort of particularly useful way >>>> (maybe >>>>>> something like dhcp-10-1-2-3- example.com). >>>>>> >>>>>> So what we need is a way for a PBX, when it reboots (or perhaps >>>>>> periodically) to say to the SSP "Here I Am; You may now send any >>>> calls >>>>>> for my assigned phone numbers to my current Contact." >>>>>> >>>>>> This is indeed a "registration" problem, but it isn't >>>> necessarily a >>>>>> "domain registration problem". The only reason domains get mixed >>>> into >>>>>> this scenario at all is that we sometimes encode telephone >>>> numbers >>>> as >>>>>> the user parts of SIP URIs, and those SIP URIs have a >> domain part >>>>>> attached to them. >>>>>> >>>>>> More interestingly, this problem is a tiny subset of the whole >>>> MARTINI >>>>>> dynamic binding problem, and it potentially can be solved >>>> much more >>>>>> simply than the general problem. >>>>>> >>>>>> On today's Interim II call, Richard, Adam and I raised >> the idea of >>>>>> dividing our problem space, and taking on a near-term >> milestone >>>> for >>>>>> delivering a MARTINI solution for registering contacts >> to a proxy, >>>> where >>>>>> that proxy maps one or more telephone numbers to the contact. >>>>>> >>>>>> We certainly intend to go on and tackle the more general domain- >>>>>> registration problem, but I (and I believe Adam and >>>> Richard) believe >>>>>> that we get a lot out of tackling the telephone-number >>>> subset first. >>>>>> >>>>>> In particular, we believe that this approach solves many of the >>>> domain >>>>>> "responsibility" questions, simplifies the TLS keying/ >>>> certification >>>>>> model immensely, eliminates the cognitive overload of >>>> using REGISTER >>>> to >>>>>> bind a "domain" to a Contact, "route authentication", >> and a good >>>> many >>>>>> other open issues that plague our current drafts. >>>>>> >>>>>> >>>>>> Open questions relating to this approach include: >>>>>> >>>>>> 1) Do we deal only with E.164 numbers, or do we need to >> deal with >>>>>> private-number "phone contexts"? >>>>>> >>>>>> 2) D owe need to explicitly encode the telephone numbers being >>>>>> registered in the REGISTER request (either directly or through >>>> some >>>> sort >>>>>> of regexp), or is it adequate to rely on provisioning of >>>> the SSP and >>>> PBX >>>>>> (and any UAs) to statically bind the numbers to the PBX >> identity, >>>> and >>>>>> then dynamically only register the PBX identity to the >>>> PBX contact? >>>>>> >>>>>> 3) Can we "register" with a tel: URI as the "To" value? (this >>>> seems >>>> to >>>>>> require extending RFC 3261)? Note that "tel:" can express >>>> both E. 164 >>>>>> numbers and private phone-contexts in one format. >>>>>> >>>>>> 4) What happens with GRUUs? >>>>>> >>>>>> I believe all of these issues are quite tractable, if >> we accept >>>> the >>>>>> fundamental idea of splitting the phone-number problem >> off from >>>> the >>>> more >>>>>> general domain-registration, and recognize the possibility >>>> that the >>>>>> solutions to the two problem may reasonably be quite >>>> different from >>>> each >>>>>> other. >>>>>> >>>>>> So, what do you people think? Is it worth trying to drink the >>>> MARTINI >>>>>> elephant one sip at a time, or are we going to treat the >>>> whole thing >>>>>> like a tequila shot and just slam it down? >>>>>> >>>>>> -- >>>>>> Dean >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> martini mailing list >>>>>> martini@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>>> _______________________________________________ >>>> martini mailing list >>>> martini@ietf.org >>>> https://www.ietf.org/mailman/listinfo/martini >>>> >>> >>> ********************************* >>> This message and any attachments (the "message") are confidential >>> and intended solely for the addressees. >>> Any unauthorised use or dissemination is prohibited. >>> Messages are susceptible to alteration. >>> France Telecom Group shall not be liable for the message if >> altered, >>> changed or falsified. >>> If you are not the intended addressee of this message, >> please cancel >>> it immediately and inform the sender. >>> ******************************** >>> >> >> > > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** > _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From eburger@standardstrack.com Fri Jan 29 16:45:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32703A6940 for ; Fri, 29 Jan 2010 16:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4fginuOxAHL for ; Fri, 29 Jan 2010 16:45:57 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 211073A6830 for ; Fri, 29 Jan 2010 16:45:57 -0800 (PST) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.178]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nb1TZ-0005RK-VD; Fri, 29 Jan 2010 16:46:14 -0800 From: Eric Burger To: Spencer Dawkins In-Reply-To: X-Priority: 3 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com><10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr><84635F3C80D944849BB87F5AA9E093EA@china.huawei.com><2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> Message-Id: <4629A374-FF05-4754-8D8F-A4B1064AFDBF@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jan 2010 19:46:16 -0500 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: Cc: martini@ietf.org Subject: Re: [martini] Proposed worksplit:tackletelephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 00:45:59 -0000 I know, a bunch of folks jumpped on me for confusing DRINKS and DREGS. =20= Too many martinis and, if you follow my tweets, too much wine with =20 real dregs in it, clearly... I would offer a tag that means "this SIP URI is a phone number" is =20 equivalent in work to "tel:mumble". I was hoping to ignore that issue =20= whole cloth... On Jan 29, 2010, at 7:36 PM, Spencer Dawkins wrote: > Hi, Eric, > > A couple of things: > > - MARTINI came from DREGS (DRINKS is the OTHER alcohol-related =20 > working group > in RAI) - just in case anyone might be trying to trace the DRINKS-=20 > MARTINI link... > > - it seems to me that we're leaping from "E.164 numbers" - and I =20 > agree that > DREGS and about a million other conversations keep telling us "E.164 =20= > numbers > would be easier, and are the only things that matter, anyway" - to =20 > tel: > URIs, which have only been under serious consideration for a few days. > > We're only fascinated with tel: URIs because tel: URIs can be =20 > unambiguously > identified as globally unique, and we haven't come up with any other =20= > way of > doing that. > > If we defined a new option tag that meant "globally unique E.164 =20 > number" for > SIP URIs, would that give us what we need, without moving to tel: =20 > URIs? > > Thanks, > > Spencer > > ----- Original Message ----- From: "Eric Burger" = > > To: > Cc: > Sent: Friday, January 29, 2010 6:13 PM > Subject: Re: [martini] Proposed worksplit:tackletelephone-=20 > numberregistration > first > > > Sorry, but the AVERAGE time to take something from ID-0 to RFC is 48 > months. > > E.164-only has a chance because it has been worked on for over two > years and there was virtually unanimous buy-in at the DRINKS BOF > (which became the MARTINI work group) that if the problem domain was > restricted to E.164 numbers, then the proposed approach would be > acceptable. > > Any generic approach will not have such support and will take the > normal IETF discussion period of 3-5 years. > > Longer if it involves INFO :-) [Inside joke for old SIP folks] > > > On Jan 29, 2010, at 11:28 AM, > > wrote: > >> Of course we do not need a solution in 3-5 years. However I hardly >> believe that a generic solution would require 3-5 years if the E.=20 >> 164- only >> solutions requires only 2 or 3 months. >> >> I also understand that doing the E.164-only solution today does =20 >> not mean >> we ignore the long-term problem. However I still think that an E.=20 >> 164-only >> solution has almost no value compared to the current 3GPP/ ETSI =20 >> solution, >> especially if the long-term solution significantly differs from the >> E.164-only solution. I'm not convinced that the issues identified =20= >> with >> the 3GPP/ETSI/IMS solution prevent implementing it even outside the >> context of the IMS. I'm aware of a number of PBX on the market =20 >> than can >> already accept an inbound INVITE request with a Request-URI =20 >> containing >> either the registered contact or one of the implictly or explictly >> registered AoRs. >> >> BC >> >>> -----Message d'origine----- >>> De : Eric Burger [mailto:eburger@standardstrack.com] >>> Envoy=E9 : vendredi 29 janvier 2010 15:41 >>> =C0 : CHATRAS Bruno RD-CORE-ISS >>> Cc : martini@ietf.org >>> Objet : Re: [martini] Proposed work >>> split:tackletelephone-numberregistration first >>> >>> On the one hand, I agree we have to work on a general >>> mechanism to enable the SP to provision IP PBXen as well as >>> an efficient way for IP PBXen to register endpoints to an SP. >>> >>> On the other hand, are you willing to wait 3-5 years for the >>> general mechanism? More especially so given the industry >>> today is 99.9% E.164 numbers and needs a solution last year? >>> This is a serious question: if service providers are saying, >>> "This is going to be important, but we really do not need a >>> solution in 3-5 years," then that informs our >>> work: we can relax and engineer the perfect solution. >>> However, almost all of the service providers I speak with >>> say, "A solution to this problem is already a year late. If >>> we do not see something soon [2-3 months] we are going to >>> codify and deploy the (admittedly broken) REGISTER method >>> that we are already using, with or without the IETF. >>> It would be nice if we could have a not-so-broken mechanism, >>> but the market has lost its patience." >>> >>> Again, doing the E.164-only solution today does not mean we >>> ignore the long-term problem. >>> >>> Does this work for you? >>> >>> On Jan 29, 2010, at 8:47 AM, Spencer Dawkins wrote: >>> >>>> Hi, Bruno, >>>> >>>> My apologies for not snapping when I saw your e-mail address - I'm >>>> currently chairing three working groups, and things are getting a >>>> little blurry (MEDIACTRL *really* needs to finish soon!). >>>> >>>> Thanks for the input - it's helpful. >>>> >>>> Spencer >>>> >>>> ----- Original Message ----- From: >>> >>>> To: ; ; >>>> >>>> ; >>>> Cc: >>>> Sent: Friday, January 29, 2010 7:39 AM >>>> Subject: RE: [martini] Proposed work split:tackletelephone- >>>> numberregistration first >>>> >>>> >>>> Hi Spencer, >>>> >>>> I have seen you request on the sip-ops list where you noted that >>>> MARTINI is not getting inputs from other operators (than =20 >>>> CableLabs). >>>> I'm actually representing a fixed and mobile operator >>> (France Telecom >>>> - Orange) and as you can guess from my previous posts we support a >>>> REGISTER-based solution and believe that a solution >>> restricted to Tel >>>> URIs would be of limited interest. >>>> >>>> /BC >>>> >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : martini-bounces@ietf.org >>>>> [mailto:martini-bounces@ietf.org] De la part de Spencer Dawkins >>>>> Envoy=E9 : jeudi 28 janvier 2010 22:59 >>>>> =C0 : Brian Lindsay; Eric Burger; Dean Willis >>>>> Cc : martini@ietf.org >>>>> Objet : Re: [martini] Proposed work >>>>> split:tackletelephone-numberregistration first >>>>> >>>>> Hi, Brian, >>>>> >>>>> Thanks for the quick feedback. I'm mostly asking if I'm >>>>> reading where we are going correctly (I GOTTA get the draft >>>>> minutes out from that call!). >>>>> >>>>> This is kind of twisty-little-passages-all-alike/different >>>>> (for those of you that remember the "adventure" game in the >>>>> early 1980s), but I'm trying to follow the chain. Where I >>>>> thought we were, was that we didn't have a coherent story for >>>>> how we get a call from outside the service provider, to the >>>>> service provider, to the SIP-PBX, and I've heard a bunch of >>>>> smart guys talk for a long time on a number of occasions >>>>> about how that might work/not work, usually ending with "but >>>>> if this was limited to E.164 numbers, a lot of these problems >>>>> would go away". >>>>> >>>>> So I'm trying to laces comments from the call that I remember >>>>> together, and see what the resulting tapestry looks like. >>>>> >>>>> Tell you what. I'll go work on draft minutes and stop typing >>>>> e-mail, and we'll see if that works better :D >>>>> >>>>> Spencer >>>>> >>>>> ----- Original Message ----- >>>>> From: "Brian Lindsay" >>>>> To: "Spencer Dawkins" ; "Eric Burger" >>>>> ; "Dean Willis" >>>>> >>>>> Cc: >>>>> Sent: Thursday, January 28, 2010 3:48 PM >>>>> Subject: RE: [martini] Proposed work split: >>>>> tackletelephone-numberregistration first >>>>> >>>>> >>>>> Hi Spencer, >>>>> >>>>> I am not sure if this is going down the path that the >>>>> actual register >>>>> request uses a Tel: URI. >>>>> >>>>> If so, I don't see why that needs to be the case. The >>>>> REGISTER itself >>>>> can still be done per Martini-Shaken with a SIP URI >>>>> representing the SIP >>>>> PBX. In fact, I am not sure too much has to change with Martini- >>>>> Shaken >>>>> unless you want to enforce use of a Tel URI format for >>> requests sent >>>>> towards the SIP PBX. >>>>> >>>>> Thanks >>>>> Brian >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] =20= >>>>> On >>>>> Behalf Of Spencer Dawkins >>>>> Sent: Thursday, January 28, 2010 4:39 PM >>>>> To: Eric Burger; Dean Willis >>>>> Cc: martini@ietf.org >>>>> Subject: Re: [martini] Proposed work split: >>>>> tackletelephone-numberregistration first >>>>> >>>>> OK, this discussion continues to be lovely. Thanks again for >>>>> listening >>>>> to the people you're talking to ("plays well with others" is >>>>> under-appreciated, once we get out of primary school, but *I* >>>>> appreciate >>>>> it!) >>>>> >>>>> After reading this thread down through Eric's note below, >>> I have a >>>>> few >>>>> requests, as co-chair. >>>>> >>>>> We're talking about E.164 numbers like we can easily >>> identify them. >>>>> My >>>>> understanding from Tuesday's call was that people on the >>> call thought >>>>> the only way we could unambiguously know that we had an E.164 >>>>> number was >>>>> if we had a tel: URI. If people on this list want to challenge =20 >>>>> that >>>>> assertion, this would be a great time to say so - please push >>>>> back Real >>>>> Soon Now. >>>>> >>>>> If that's true, we're talking about using Tel: URIs. Dean has >>>>> asserted >>>>> that this would require an update to 3261. I'm not a genius >>>>> of 3261, but >>>>> some of you guys are - could you point us to what you think >>>>> needs to be >>>>> updated? >>>>> >>>>> My quick read turned up this text in Section 4, page 17: >>>>> >>>>> Registration is another common operation in SIP. >>>>> Registration is one >>>>> way that the biloxi.com server can learn the current >>>>> location of Bob. >>>>> Upon initialization, and at periodic intervals, Bob's SIP >>>>> phone sends >>>>> REGISTER messages to a server in the biloxi.com domain >>>>> known as a SIP >>>>> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >>>>> (sip:bob@biloxi.com) with the machine into which he is currently >>>>> logged (conveyed as a SIP or SIPS URI in the Contact >>> header field). >>>>> >>>>> Dean, Is this what you were thinking of? Are there other >>> places that >>>>> also need to change? >>>>> >>>>> As I read http://www.ietf.org/id/draft-peterson-rai- >>>>> rfc3427bis-04.txt, >>>>> Section 2.1, this change would have to go through SIPCORE, >>>>> because it's >>>>> an update to 3261. If you know of obvious land mines that >>> we would be >>>>> walking into if we propose this change, please say so Real >>> Soon Now. >>>>> (One obvious land mine is that DISPATCH isn't meeting in >>>>> Anaheim, so the >>>>> proposal would have to be DISPATCHed on the mailing list in >>>>> order to do >>>>> something before IETF 78 - are there OTHERS?) >>>>> >>>>> Finally, if you believe that embracing tel: URIs is the >>> wrong thing >>>>> to >>>>> do, please say so, Real Soon Now. >>>>> >>>>> The milestones that we committed to in >>>>> http://tools.ietf.org/wg/martini/charters have us adopting >>> a working >>>>> group SOLUTION draft in January. We're not late yet, but it's the >>>>> 28th >>>>> of January in my time zone. If we are late, where late is >>> measured in >>>>> days, I can live with that, but if we are late, where late is >>>>> measured >>>>> in IETF meeting cycles, that's going to be a problem. >>>>> >>>>> Thanks, >>>>> >>>>> Spencer, as co-chair >>>>> >>>>> ----- Original Message ----- >>>>> From: "Eric Burger" >>>>> To: "Dean Willis" >>>>> Cc: >>>>> Sent: Thursday, January 28, 2010 12:32 PM >>>>> Subject: Re: [martini] Proposed work split: tackle >>>>> telephone-numberregistration first >>>>> >>>>> >>>>>> If you ask me (why can't I stay in retirement?), the E.164 >>>>> situation >>>>> is >>>>>> not only a simplification, but just about the only thing that is >>>>> sensible >>>>>> for MARTINI to work on. >>>>>> >>>>>> The E.164 situation is a clear, present, >>> industry-is-begging-for-a- >>>>>> solution problem. It is so pressing, the industry will tell us >>>>> (the >>>>>> IETF) to get stuffed and do something stupid if we cannot deliver >>>>>> something that is not at its core fundamentally broken. >>>>>> >>>>>> I do not think anyone can have an issue with mechanisms >>>>> that translate >>>>> a >>>>>> string of digits into an AOR that might cross domain boundaries. >>>>> This is >>>>>> the E.164 problem statement. >>>>>> >>>>>> If think everyone (with a brain) SHOULD have issues with a >>>>> mechanism >>>>> that >>>>>> magically mungs "sip:eburger@neustar.biz" into >>>>> "sip:5350@pbx.example.net " >>>>>> while at the same time www.neustar.biz is really a neustar.biz >>>>> domain. >>>>>> That really would be creating a parallel DNS, which, as >>> one of the >>>>> major >>>>>> DNS operators, would really, really be "less than ideal" and >>>>> have a >>>>> whole >>>>>> host of security and integrity issues. >>>>>> >>>>>> THEREFORE, I would propose that we split this work into >>> two phases: >>>>>> Phase 1: Deliver an E.164 solution, preferably in the next few >>>>> months, >>>>>> so the industry does not ignore the IETF. >>>>>> >>>>>> Phase 2: Deliver the generic solution in the normal, 3-5 year >>>>> IETF >>>>>> cycle. This generic solution may or may not encompass >>>>> E.164 numbers. >>>>> As >>>>>> Doug Sauder points out, E.164 numbers and their >>> infrastructure are >>>>>> different. Thus a different E.164 registration model from >>>>> generic SIP >>>>>> URI provisioning models would neither be a burden on industry nor >>>>> create >>>>>> backwards-compatibility issues for the generic solution. >>>>>> >>>>>> Note that if we do not deliver Phase 1 in a very, very >>>>> timely manner, >>>>> the >>>>>> less-than-idea industry solution just might blow up the >>>>> possibility >>>>> for >>>>>> the generic solution, which would be considerably less >>> than ideal. >>>>>> >>>>>> On Jan 27, 2010, at 1:16 AM, Dean Willis wrote: >>>>>> >>>>>>> >>>>>>> We seem to have an urgent need for a near-term solution for >>>>> dealing >>>>> with >>>>>>> the subset of the MARTINI problem that, loosely defined, >>>>> covers the >>>>>>> "telephone number" problem. >>>>>>> >>>>>>> The typical scenario here is SIP trunking, wherein a SIP Service >>>>>>> Provider (SSP) provides an ISDN-PRI like service over IP to a >>>>> customer's >>>>>>> PBX (or PBXes). In this model, the SSP maps a whole bunch >>>>> of phone >>>>>>> numbers to the PBXes. This mapping is somewhat dynamic, >>>>> because the >>>>>>> PBXes usually have DHCP addresses, and don't have DNS entries >>>>> that >>>>> point >>>>>>> A records at the PBX in any sort of particularly useful way >>>>> (maybe >>>>>>> something like dhcp-10-1-2-3- example.com). >>>>>>> >>>>>>> So what we need is a way for a PBX, when it reboots (or perhaps >>>>>>> periodically) to say to the SSP "Here I Am; You may now send any >>>>> calls >>>>>>> for my assigned phone numbers to my current Contact." >>>>>>> >>>>>>> This is indeed a "registration" problem, but it isn't >>>>> necessarily a >>>>>>> "domain registration problem". The only reason domains get mixed >>>>> into >>>>>>> this scenario at all is that we sometimes encode telephone >>>>> numbers >>>>> as >>>>>>> the user parts of SIP URIs, and those SIP URIs have a >>> domain part >>>>>>> attached to them. >>>>>>> >>>>>>> More interestingly, this problem is a tiny subset of the whole >>>>> MARTINI >>>>>>> dynamic binding problem, and it potentially can be solved >>>>> much more >>>>>>> simply than the general problem. >>>>>>> >>>>>>> On today's Interim II call, Richard, Adam and I raised >>> the idea of >>>>>>> dividing our problem space, and taking on a near-term >>> milestone >>>>> for >>>>>>> delivering a MARTINI solution for registering contacts >>> to a proxy, >>>>> where >>>>>>> that proxy maps one or more telephone numbers to the contact. >>>>>>> >>>>>>> We certainly intend to go on and tackle the more general domain- >>>>>>> registration problem, but I (and I believe Adam and >>>>> Richard) believe >>>>>>> that we get a lot out of tackling the telephone-number >>>>> subset first. >>>>>>> >>>>>>> In particular, we believe that this approach solves many of the >>>>> domain >>>>>>> "responsibility" questions, simplifies the TLS keying/ >>>>> certification >>>>>>> model immensely, eliminates the cognitive overload of >>>>> using REGISTER >>>>> to >>>>>>> bind a "domain" to a Contact, "route authentication", >>> and a good >>>>> many >>>>>>> other open issues that plague our current drafts. >>>>>>> >>>>>>> >>>>>>> Open questions relating to this approach include: >>>>>>> >>>>>>> 1) Do we deal only with E.164 numbers, or do we need to >>> deal with >>>>>>> private-number "phone contexts"? >>>>>>> >>>>>>> 2) D owe need to explicitly encode the telephone numbers being >>>>>>> registered in the REGISTER request (either directly or through >>>>> some >>>>> sort >>>>>>> of regexp), or is it adequate to rely on provisioning of >>>>> the SSP and >>>>> PBX >>>>>>> (and any UAs) to statically bind the numbers to the PBX >>> identity, >>>>> and >>>>>>> then dynamically only register the PBX identity to the >>>>> PBX contact? >>>>>>> >>>>>>> 3) Can we "register" with a tel: URI as the "To" value? (this >>>>> seems >>>>> to >>>>>>> require extending RFC 3261)? Note that "tel:" can express >>>>> both E. 164 >>>>>>> numbers and private phone-contexts in one format. >>>>>>> >>>>>>> 4) What happens with GRUUs? >>>>>>> >>>>>>> I believe all of these issues are quite tractable, if >>> we accept >>>>> the >>>>>>> fundamental idea of splitting the phone-number problem >>> off from >>>>> the >>>>> more >>>>>>> general domain-registration, and recognize the possibility >>>>> that the >>>>>>> solutions to the two problem may reasonably be quite >>>>> different from >>>>> each >>>>>>> other. >>>>>>> >>>>>>> So, what do you people think? Is it worth trying to drink the >>>>> MARTINI >>>>>>> elephant one sip at a time, or are we going to treat the >>>>> whole thing >>>>>>> like a tequila shot and just slam it down? >>>>>>> >>>>>>> -- >>>>>>> Dean >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> martini mailing list >>>>>>> martini@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/martini >>>>>> >>>>>> _______________________________________________ >>>>>> martini mailing list >>>>>> martini@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>>> _______________________________________________ >>>>> martini mailing list >>>>> martini@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/martini >>>>> >>>> >>>> ********************************* >>>> This message and any attachments (the "message") are confidential >>>> and intended solely for the addressees. >>>> Any unauthorised use or dissemination is prohibited. >>>> Messages are susceptible to alteration. >>>> France Telecom Group shall not be liable for the message if >>> altered, >>>> changed or falsified. >>>> If you are not the intended addressee of this message, >>> please cancel >>>> it immediately and inform the sender. >>>> ******************************** >>>> >>> >>> >> >> ********************************* >> This message and any attachments (the "message") are confidential =20= >> and >> intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if altered, >> changed or falsified. >> If you are not the intended addressee of this message, please =20 >> cancel it >> immediately and inform the sender. >> ******************************** >> > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From dean.willis@softarmor.com Fri Jan 29 21:21:46 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB133A6864 for ; Fri, 29 Jan 2010 21:21:46 -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 s8qYuYq8WY+L for ; Fri, 29 Jan 2010 21:21:45 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B7F283A681E for ; Fri, 29 Jan 2010 21:21:45 -0800 (PST) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0U5M5ma028393; Fri, 29 Jan 2010 23:22:05 -0600 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Sat, 30 Jan 2010 05:22:05 -0000 (UTC) Message-ID: <03e49e13402c3b3bb59dce2358c56fae.squirrel@www.softarmor.com> In-Reply-To: <4B61CE78.20605@cisco.com> References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <4B61CE78.20605@cisco.com> Date: Sat, 30 Jan 2010 05:22:05 -0000 (UTC) From: "Dean Willis" To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:21:46 -0000 On Thu, January 28, 2010 5:50 pm, Paul Kyzivat wrote: > It could if *it* registered the domain names on behalf of the customers. > But if the customer says to the SSP "I already own this domain and will > arrange for requests to it to be routed to you, so when you get them > please forward them on to my pbx", how is the SSP to decide if that is > ok or not? Google mail solves exactly this problem by 1) making one prove that one can receive emails to the address in question, and 2) making one prove that one can make DNS changes by putting a "cookie" record into the zone. -- dean From bernard_aboba@hotmail.com Fri Jan 29 21:26:38 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC42B3A681E for ; Fri, 29 Jan 2010 21:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 33doneLGZiru for ; Fri, 29 Jan 2010 21:26:38 -0800 (PST) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by core3.amsl.com (Postfix) with ESMTP id EDED93A6407 for ; Fri, 29 Jan 2010 21:26:37 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.72]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:27:02 -0800 X-Originating-IP: [131.107.0.77] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com><130895FDE1B4488C82158D051A1D94D9@china.huawei.com><09B7DBFE70A9E24BBB21689DAD3A06141C49D25F@zcarhxm1.corp.nortel.com><10783_1264772389_4B62E525_10783_1447_1_9ECCF01B52E7AB408A7EB8535264214101082C05@ftrdmel0.rd.francetelecom.fr><84635F3C80D944849BB87F5AA9E093EA@china.huawei.com><2700_1264782482_4B630C91_2700_685_1_9ECCF01B52E7AB408A7EB8535264214101082F0E@ftrdmel0.rd.francetelecom.fr> <4629A374-FF05-4754-8D8F-A4B1064AFDBF@standardstrack.com> In-Reply-To: <4629A374-FF05-4754-8D8F-A4B1064AFDBF@standardstrack.com> Date: Fri, 29 Jan 2010 21:27:02 -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: AcqhRaEITft962L0QH6VgkQiSVFZRQAJGKGw Content-Language: en-us X-OriginalArrivalTime: 30 Jan 2010 05:27:02.0519 (UTC) FILETIME=[DA578870:01CAA16C] Subject: Re: [martini] the MARTINI conundrum X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:26:38 -0000 Bruno Chatras said: "I'm not convinced that the issues identified with the 3GPP/ETSI/IMS solution prevent implementing it even outside the context of the IMS. I'm aware of a number of PBX on the market than can already accept an inbound INVITE request with a Request-URI containing either the registered contact or one of the implictly or explictly registered AoRs." [BA] Unfortunately, the same statements can be made with respect to some of the other "implicit registration" approaches that exist in the field. Each scheme is supported by some PBXes and some service providers. The problem is that there is no one scheme that is supported by everyone. That said, it's not always the case that situations like this can be improved by introduction of a new approach. Sometimes the easiest road to interoperability when there are multiple deployed variants is for vendors to accept the inevitability of diversity and learn to live with it. Once a vendor has implemented the most popular variants, they can sometimes cope with diversity well enough to make life tolerable. At that point, vendors typically consider the problem solved and move on to the next squeaky wheel. So while today we might still be hoping for "change we can believe in", at some point, we'll either have created a bridge that the SSP/PBX community is willing to cross or we won't. If we can get them to the other side, then we *might* have a shot at moving beyond today's somewhat cluttered urban landscape to the beautiful green field beyond. But getting them to move will not be easy, even given all the issues we have enumerated. From dean.willis@softarmor.com Fri Jan 29 21:28:45 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C067B3A6781 for ; Fri, 29 Jan 2010 21:28:45 -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 sg9LWHhH+XJI for ; Fri, 29 Jan 2010 21:28:44 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D13B73A6407 for ; Fri, 29 Jan 2010 21:28:44 -0800 (PST) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0U5T3PS028497; Fri, 29 Jan 2010 23:29:06 -0600 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Sat, 30 Jan 2010 05:29:06 -0000 (UTC) Message-ID: <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> In-Reply-To: <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> Date: Sat, 30 Jan 2010 05:29:06 -0000 (UTC) From: "Dean Willis" To: "Spencer Dawkins" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:28:45 -0000 On Thu, January 28, 2010 9:39 pm, Spencer Dawkins wrote: > Registration is another common operation in SIP. Registration is one > way that the biloxi.com server can learn the current location of Bob. > Upon initialization, and at periodic intervals, Bob's SIP phone sends > REGISTER messages to a server in the biloxi.com domain known as a SIP > registrar. The REGISTER messages associate Bob's SIP or SIPS URI > (sip:bob@biloxi.com) with the machine into which he is currently > logged (conveyed as a SIP or SIPS URI in the Contact header field). > > Dean, Is this what you were thinking of? Are there other places that also > need to change? Adam was asserting the need to change 3261, whereas I was asking if we need to change it. I think we have a slight thought-disconnect, as I'm considering registration with a SIP/SIPS URI as the Contact, but a TEL URI as the "To:" value. Adam seems to want to register a TEL Contact, which makes no sense to me. -- Dean From dean.willis@softarmor.com Fri Jan 29 21:36:44 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3893A681E for ; Fri, 29 Jan 2010 21:36:44 -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 4rhUneNt0Da2 for ; Fri, 29 Jan 2010 21:36:43 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DD63C3A680C for ; Fri, 29 Jan 2010 21:36:41 -0800 (PST) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0U5b1j8028640; Fri, 29 Jan 2010 23:37:01 -0600 Received: from 65.65.155.30 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Sat, 30 Jan 2010 05:37:02 -0000 (UTC) Message-ID: In-Reply-To: <4B62ED8D.9050503@cisco.com> References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B62ED8D.9050503@cisco.com> Date: Sat, 30 Jan 2010 05:37:02 -0000 (UTC) From: "Dean Willis" To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:36:45 -0000 On Fri, January 29, 2010 2:15 pm, Paul Kyzivat wrote: > To: The To header field contains the address of record whose > registration is to be created, queried, or modified. The To > header field and the Request-URI field typically differ, as > the former contains a user name. This address-of-record MUST > be a SIP URI or SIPS URI. > Thanks, Paul. This is exactly the part of 3261 that I think would need to be changed; the "To" field can be either a tel: URI, or perhaps a wildcarded/regexed expression for a rane of tel: URIs. -- dean From spencer@wonderhamster.org Sat Jan 30 08:07:57 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1473A68A8 for ; Sat, 30 Jan 2010 08:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, STOX_REPLY_TYPE=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 MW6Q0PIBOf70 for ; Sat, 30 Jan 2010 08:07:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 361363A67D1 for ; Sat, 30 Jan 2010 08:07:56 -0800 (PST) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MHoSj-1NccmG3JaX-003k3U; Sat, 30 Jan 2010 11:08:11 -0500 Message-ID: From: "Spencer Dawkins" To: "Dean Willis" References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> Date: Sat, 30 Jan 2010 10:07:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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: V01U2FsdGVkX18mLCqJr9SOrbxCGH0LlE+cWtdUNBKXe9C33bI ODRCMUnmXyZOWS5kusPeyeU+/7Y+8vByjmvqETJs0CBqfepZHp WT0HTHt0/umeyUhXt+QVys3UYaoV6igj1+eiE6Yfko= Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 16:07:57 -0000 Hi, Dean, > >> Registration is another common operation in SIP. Registration is one >> way that the biloxi.com server can learn the current location of Bob. >> Upon initialization, and at periodic intervals, Bob's SIP phone sends >> REGISTER messages to a server in the biloxi.com domain known as a SIP >> registrar. The REGISTER messages associate Bob's SIP or SIPS URI >> (sip:bob@biloxi.com) with the machine into which he is currently >> logged (conveyed as a SIP or SIPS URI in the Contact header field). >> >> Dean, Is this what you were thinking of? Are there other places that also >> need to change? > > Adam was asserting the need to change 3261, whereas I was asking if we > need to change it. I think we have a slight thought-disconnect, as I'm > considering registration with a SIP/SIPS URI as the Contact, but a TEL URI > as the "To:" value. Adam seems to want to register a TEL Contact, which > makes no sense to me. Dean and Adam: My apologies for misattributing here. I agree that we seem to be talking about multiple things at once. I'd love to see a call flow that discusses what we're talking about now - Adam has produced several helpful ones already, but he did so before we were focused on tel as a possibility. Thanks, Spencer From adam@nostrum.com Sat Jan 30 08:39:47 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BBE23A67AC for ; Sat, 30 Jan 2010 08:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 v5VseoehSJE0 for ; Sat, 30 Jan 2010 08:39:46 -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 3F9273A67A6 for ; Sat, 30 Jan 2010 08:39:45 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o0UGeAa3001135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 10:40:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B6460EA.8050102@nostrum.com> Date: Sat, 30 Jan 2010 10:40:10 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Dean Willis References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> In-Reply-To: <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 16:39:47 -0000 On 1/29/10 23:29, Jan 29, Dean Willis wrote: > Adam was asserting the need to change 3261... I don't recall making such an assertion. Perhaps you confused someone else with me? /a From pkyzivat@cisco.com Sat Jan 30 10:12:59 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE1B3A672F for ; Sat, 30 Jan 2010 10:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo4KsB1iRAiU for ; Sat, 30 Jan 2010 10:12:58 -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 426983A63D3 for ; Sat, 30 Jan 2010 10:12:58 -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: ApoEAD4FZEutJV2d/2dsb2JhbADBZJc8hEUE X-IronPort-AV: E=Sophos;i="4.49,375,1262563200"; d="scan'208";a="294102400" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-1.cisco.com with ESMTP; 30 Jan 2010 18:13:25 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o0UIDOxh019955; Sat, 30 Jan 2010 18:13:24 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:13:24 -0600 Received: from [10.86.244.230] ([10.86.244.230]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:13:24 -0600 Message-ID: <4B6476C3.8040905@cisco.com> Date: Sat, 30 Jan 2010 13:13:23 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <4B61CE78.20605@cisco.com> <03e49e13402c3b3bb59dce2358c56fae.squirrel@www.softarmor.com> In-Reply-To: <03e49e13402c3b3bb59dce2358c56fae.squirrel@www.softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2010 18:13:24.0321 (UTC) FILETIME=[E9A1B510:01CAA1D7] Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 18:12:59 -0000 Dean Willis wrote: > On Thu, January 28, 2010 5:50 pm, Paul Kyzivat wrote: > >> It could if *it* registered the domain names on behalf of the customers. >> But if the customer says to the SSP "I already own this domain and will >> arrange for requests to it to be routed to you, so when you get them >> please forward them on to my pbx", how is the SSP to decide if that is >> ok or not? > > Google mail solves exactly this problem by 1) making one prove that one > can receive emails to the address in question, and 2) making one prove > that one can make DNS changes by putting a "cookie" record into the zone. But isn't the whole point here that the pbx *can't* be reached at its domain name using DNS lookup? This connection is supposed to be in lieu of such a direct connection. Paul From pkyzivat@cisco.com Sat Jan 30 10:25:28 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C923A680D for ; Sat, 30 Jan 2010 10:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 MhgSnKiEBOLS for ; Sat, 30 Jan 2010 10:25:27 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 257343A672F for ; Sat, 30 Jan 2010 10:25:27 -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: ApoEAEoIZEutJV2a/2dsb2JhbADBX5c8glMMgWYE X-IronPort-AV: E=Sophos;i="4.49,375,1262563200"; d="scan'208";a="82950282" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 30 Jan 2010 18:25:53 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o0UIPqmP017473; Sat, 30 Jan 2010 18:25:52 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:25:52 -0600 Received: from [10.86.244.230] ([10.86.244.230]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:25:52 -0600 Message-ID: <4B6479AF.5020202@cisco.com> Date: Sat, 30 Jan 2010 13:25:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <4B62ED8D.9050503@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2010 18:25:52.0372 (UTC) FILETIME=[A7813B40:01CAA1D9] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 18:25:28 -0000 Dean Willis wrote: > On Fri, January 29, 2010 2:15 pm, Paul Kyzivat wrote: > >> To: The To header field contains the address of record whose >> registration is to be created, queried, or modified. The To >> header field and the Request-URI field typically differ, as >> the former contains a user name. This address-of-record MUST >> be a SIP URI or SIPS URI. >> > > Thanks, Paul. This is exactly the part of 3261 that I think would need to > be changed; the "To" field can be either a tel: URI, or perhaps a > wildcarded/regexed expression for a rane of tel: URIs. My understanding was that the To of the REGISTER would be a special sip URI. The phone numbers (perhaps TEL URIs) would be *implicitly* registered. As such they they would never be the To of a register, and so would not violate the letter of 3261. Whether it breaks the spirit of 3261 to implicitly register a TEL is arguable. Thanks, Paul From pkyzivat@cisco.com Sat Jan 30 10:28:13 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633E83A680D for ; Sat, 30 Jan 2010 10:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.849 X-Spam-Level: X-Spam-Status: No, score=-10.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwWxr2ISX01G for ; Sat, 30 Jan 2010 10:28:12 -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 999F63A672F for ; Sat, 30 Jan 2010 10:28:12 -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: ApoEAMIIZEutJV2Z/2dsb2JhbADBZJc8hEUE X-IronPort-AV: E=Sophos;i="4.49,375,1262563200"; d="scan'208";a="294103472" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-1.cisco.com with ESMTP; 30 Jan 2010 18:28:39 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o0UISd72014705; Sat, 30 Jan 2010 18:28:39 GMT Received: from xfe-rcd-102.cisco.com ([72.163.62.137]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:28:39 -0600 Received: from [10.86.244.230] ([10.86.244.230]) by xfe-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 12:28:38 -0600 Message-ID: <4B647A55.4060300@cisco.com> Date: Sat, 30 Jan 2010 13:28:37 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> <4B6460EA.8050102@nostrum.com> In-Reply-To: <4B6460EA.8050102@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2010 18:28:38.0670 (UTC) FILETIME=[0AA04AE0:01CAA1DA] Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 18:28:13 -0000 Adam Roach wrote: > On 1/29/10 23:29, Jan 29, Dean Willis wrote: >> Adam was asserting the need to change 3261... > > I don't recall making such an assertion. Perhaps you confused someone > else with me? It may have been me. But I think it remains to be seen if what we are talking about requires any changes. Thanks, Paul From bernard_aboba@hotmail.com Sat Jan 30 19:12:18 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E923A67A8 for ; Sat, 30 Jan 2010 19:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_05=-1.11, 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 48eBp-kAHpwC for ; Sat, 30 Jan 2010 19:12:13 -0800 (PST) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by core3.amsl.com (Postfix) with ESMTP id 865573A67A5 for ; Sat, 30 Jan 2010 19:12:11 -0800 (PST) Received: from BLU137-DS6 ([65.55.111.73]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 30 Jan 2010 19:12:40 -0800 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sat, 30 Jan 2010 19:12:48 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01CAA1E0.36A63950" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqiI0RokodrvQAwSQqaVzi9Z6cTLg== Content-Language: en-us X-OriginalArrivalTime: 31 Jan 2010 03:12:40.0006 (UTC) FILETIME=[3F1F6E60:01CAA223] Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 03:12:18 -0000 ------=_NextPart_000_0215_01CAA1E0.36A63950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul Kyzivat said: "But isn't the whole point here that the pbx *can't* be reached at its domain name using DNS lookup? This connection is supposed to be in lieu of such a direct connection." [BA] Dynamic DNS providers are widely available and their fees are quite small compared with those of a typical SIP trunking provider, so I don't think the bottleneck is really the ability to provision SRV/NAPTR RRs or dynamically provision A/AAAA RRs. Even if such RRs were populated, service providers would prefer to utilize "implicit registration" for the purposes of determining PBX reachability. Most of SSPs don't offer DNS services, and don't have partnerships with companies that do. Given that, they'd prefer to avoid dependencies on third parties that they have no control over. However, with domain registration the SSP would have a wider set of choices: a. If you can demonstrate ownership of the domain via the mechanisms Dean mentioned, the SSP could include your proven domain in the incoming Request-URI. b. If you don't own a domain, then they'll provide you with a sub-domain for the purposes of domain registration (but probably not for DNS uses, since most SSPs don't offer that). Choice a) would come in handy in some cases. For example, I have set up PBXes that support dynamic registration, purchased domains, gotten them set up with dynamic DNS providers, etc. only to find that incoming INVITEs from the SSP still contained Request-URIs of the form @sp.com, because the SSP wasn't set up to handle anything else (at least not for the fees they were being paid). As an aside, no loops resulted from this behavior because the PBX was operating as a B2BUA, and was provisioned to treat those incoming Request-URIs as if they were registered by the PBX acting as a UA, not as though the PBX were acting as a Proxy. So from the PBXes point of view, it did not route those requests, it merely terminated them. ------=_NextPart_000_0215_01CAA1E0.36A63950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul Kyzivat said:

 

"But isn't the whole point here that the pbx = *can't* be reached at its

domain name using DNS lookup? This connection is = supposed to be in lieu

of such a direct connection."

 

[BA] Dynamic DNS providers are widely available and = their fees are quite

small compared with those of a typical SIP trunking provider, so I don't

think the bottleneck is really the ability to = provision SRV/NAPTR RRs or

dynamically provision A/AAAA RRs.

 

Even if such RRs were populated, service providers = would prefer to utilize

"implicit registration" for the purposes = of determining PBX reachability.

Most of SSPs don't offer DNS services, and don't = have partnerships with

companies that do.  Given that, they'd prefer = to avoid dependencies on

third parties that they have no control over. =

 

However, with domain registration the SSP would = have a wider set of choices:

 

a. If you can demonstrate ownership of the domain = via the mechanisms

Dean mentioned, the SSP could include your proven = domain in the incoming Request-URI.

 

b. If you don't own a domain, then they'll provide = you with a

sub-domain for the purposes of domain registration = (but probably

not for DNS uses, since most SSPs don't offer = that).

 

Choice a) would come in handy in some cases.  = For example,

I have set up PBXes that support dynamic = registration, purchased

domains, gotten them set up with dynamic DNS = providers, etc. only

to find that incoming INVITEs from the SSP still = contained

Request-URIs of the form = <phone-number>@sp.com, because

the SSP wasn’t set up to handle anything else = (at least not for

the fees they were being paid).

 

As an aside, no loops resulted from this behavior = because the

PBX was operating as a B2BUA, and was provisioned = to treat

those incoming Request-URIs as if they were = registered by

the PBX acting as a UA, not as though the PBX were = acting as a Proxy.

So from the PBXes point of view, it did not route = those requests,

it merely terminated them.

 

------=_NextPart_000_0215_01CAA1E0.36A63950-- From dean.willis@softarmor.com Sun Jan 31 10:16:08 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A023A689D for ; Sun, 31 Jan 2010 10:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 ceY38idHKt6l for ; Sun, 31 Jan 2010 10:16:08 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2D38F3A6827 for ; Sun, 31 Jan 2010 10:16:08 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VIGG7H010213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 12:16:17 -0600 Message-Id: <70D8BD61-A823-48E7-8BAA-92AA584AF9C5@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B62F45D.1010707@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: Sun, 31 Jan 2010 12:16:10 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <24308_1264673141_4B616175_24308_8956_1_9ECCF01B52E7AB408A7EB8535264214101053FEC@ftrdmel0.rd.francetelecom.fr> <4B621432.8040901@nostrum.com> <4B62F45D.1010707@cisco.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-number registrationfirst X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:16:09 -0000 On Jan 29, 2010, at 8:44 AM, Paul Kyzivat wrote: > > This may be slightly out of scope, but when TEL URIs are used in > From, To, Refer-To, etc. then there is no need to deal with issues > of whether to use the domain of the pbx, or the ssp, or to translate > between them. That's what makes them easier to specify the usage of. -- Dean From dean.willis@softarmor.com Sun Jan 31 10:19:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DB83A689D for ; Sun, 31 Jan 2010 10:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 3woN0UEWduMl for ; Sun, 31 Jan 2010 10:19:39 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 363213A6827 for ; Sun, 31 Jan 2010 10:19:39 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VIK3Pp010246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 12:20:04 -0600 Message-Id: <3D3B80E4-FC54-4C8C-9151-7F8C93D373A1@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 31 Jan 2010 12:19:57 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <4B61CE78.20605@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-number registration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:19:41 -0000 On Jan 29, 2010, at 12:02 PM, Hadriel Kaplan wrote: > >> Paul said: >> It could if *it* registered the domain names on behalf of the >> customers. >> But if the customer says to the SSP "I already own this domain and >> will >> arrange for requests to it to be routed to you, so when you get them >> please forward them on to my pbx", how is the SSP to decide if that >> is >> ok or not? > > Ummm, not to belabor the idea of using domain name registration > (though here I am belaboring it), but it *is* a domain owned by the > SSP. At least that's what draft-shaken says. We seem to be going back and forth on "domain owned by SSP" and "domain owned by PBX". While clear in "shaken", it's not clear in the larger context of this discussion as to which "domain" model we're talking about. -- Dean From dean.willis@softarmor.com Sun Jan 31 10:26:04 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60A03A6827 for ; Sun, 31 Jan 2010 10:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 vDpfZ76R57Bv for ; Sun, 31 Jan 2010 10:26:04 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 107CB3A68C0 for ; Sun, 31 Jan 2010 10:26:04 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VIQQ5A010336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 12:26:33 -0600 Message-Id: <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 31 Jan 2010 12:26:20 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:26:05 -0000 On Jan 29, 2010, at 12:38 PM, Hadriel Kaplan wrote: > > e) One of the major sticking points was whether the req- > URI is replaced with the Registered contact, or left alone, or just > retargeted. Using a Tel-URI AoR makes that no easier a decision/ > argument/issue. No, it makes it really easy. We use conventional contact routing (as per RFC 3261) and replace the request URI (a tel: URI) with the registered contact (a sip: URI in the domain of the PBX, or its ISP, or using the PBXes IP address, or whatever) just as we do for > > f) One of the concerns raised so far has been on GRUU's. Unless we > figure out how to convert GRUU's to telephone numbers, there's going > to be a need to route a request for a non-TEL-URI to the PBX and > keep it a non-TEL-URI. GRUUs don't convert to telephone numbers. They map SIP Contact URIs (in whatever domain they exist) to SIP URIs in the domain of the GRUU minter. This is a pretty straightforward mapping, and the issues of "domain ownership" around it have already been solved. Yes, we need more work on minting GRUUs for "wildcard" registrations, but that's a rather more tractable problem, although AFAIK untouched by any existing draft. -- Dean From dean.willis@softarmor.com Sun Jan 31 10:30:11 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487503A698B for ; Sun, 31 Jan 2010 10:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 Y780wTs2+tCV for ; Sun, 31 Jan 2010 10:30:10 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 60CF83A6989 for ; Sun, 31 Jan 2010 10:30:10 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VIUcDn010388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 12:30:40 -0600 Message-Id: <7494C6A0-2594-4A4C-B9FA-54555B8EBDBB@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B6460EA.8050102@nostrum.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: Sun, 31 Jan 2010 12:30:32 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <604473449b80b56e0a77a4772fb90709.squirrel@www.softarmor.com> <4B6460EA.8050102@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 18:30:11 -0000 On Jan 30, 2010, at 10:40 AM, Adam Roach wrote: > On 1/29/10 23:29, Jan 29, Dean Willis wrote: >> Adam was asserting the need to change 3261... > > I don't recall making such an assertion. Perhaps you confused > someone else with me? I believe you're the one who, on our interim call, asserted that RFC 3261 does not allow the use of tel: URIs in the To: field of a SIP REGISTER request. Paul later cited RFC 3261 speciifcally proving this assertion, so I'm crediting you with something that was proven to be 100% correct. -- Dean From HKaplan@acmepacket.com Sun Jan 31 12:12:40 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497C53A68C4 for ; Sun, 31 Jan 2010 12:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 T2VjmSD1IUjk for ; Sun, 31 Jan 2010 12:12:39 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5388A3A6876 for ; Sun, 31 Jan 2010 12:12:39 -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; Sun, 31 Jan 2010 15:13:08 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 31 Jan 2010 15:13:07 -0500 From: Hadriel Kaplan To: Dean Willis Date: Sun, 31 Jan 2010 15:13:06 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqiovfUaX7qXxLDRRmCJkTQujfN/wADIcXw Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> In-Reply-To: <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.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: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 20:12:40 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, January 31, 2010 1:26 PM > To: Hadriel Kaplan >=20 > On Jan 29, 2010, at 12:38 PM, Hadriel Kaplan wrote: > > e) One of the major sticking points was whether the req- > > URI is replaced with the Registered contact, or left alone, or just > > retargeted. Using a Tel-URI AoR makes that no easier a decision/ > > argument/issue. >=20 > No, it makes it really easy. We use conventional contact routing (as > per RFC 3261) and replace the request URI (a tel: URI) with the > registered contact (a sip: URI in the domain of the PBX, or its ISP, > or using the PBXes IP address, or whatever) just as we do for The request-URI would not have been a Tel-URI when the registrar-proxy got = it from the originator, but let's assume that it was: you still can't just/= solely replace the req-URI with the registered contact URI, since that woul= d lose the intended target info (the specific user phone number which is be= ing targeted). =20 > > f) One of the concerns raised so far has been on GRUU's. Unless we > > figure out how to convert GRUU's to telephone numbers, there's going > > to be a need to route a request for a non-TEL-URI to the PBX and > > keep it a non-TEL-URI. >=20 >=20 > GRUUs don't convert to telephone numbers. They map SIP Contact URIs > (in whatever domain they exist) to SIP URIs in the domain of the GRUU > minter. This is a pretty straightforward mapping, and the issues of > "domain ownership" around it have already been solved. > Yes, we need more work on minting GRUUs for "wildcard" registrations, > but that's a rather more tractable problem, although AFAIK untouched > by any existing draft. Yes, that was my point: GRUU's don't map to telephone numbers.=20 -hadriel From dean.willis@softarmor.com Sun Jan 31 14:26:56 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CAF73A68AA for ; Sun, 31 Jan 2010 14:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 zvEqhJzUb25z for ; Sun, 31 Jan 2010 14:26:55 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 46CC63A67D9 for ; Sun, 31 Jan 2010 14:26:55 -0800 (PST) Received: from [10.188.233.210] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0VMRJ5V011713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2010 16:27:20 -0600 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 31 Jan 2010 16:27:13 -0600 References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 22:26:56 -0000 On Jan 31, 2010, at 2:13 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Sunday, January 31, 2010 1:26 PM >> To: Hadriel Kaplan >> >> On Jan 29, 2010, at 12:38 PM, Hadriel Kaplan wrote: >>> e) One of the major sticking points was whether the req- >>> URI is replaced with the Registered contact, or left alone, or just >>> retargeted. Using a Tel-URI AoR makes that no easier a decision/ >>> argument/issue. >> >> No, it makes it really easy. We use conventional contact routing (as >> per RFC 3261) and replace the request URI (a tel: URI) with the >> registered contact (a sip: URI in the domain of the PBX, or its ISP, >> or using the PBXes IP address, or whatever) just as we do for > > The request-URI would not have been a Tel-URI when the registrar- > proxy got it from the originator, but let's assume that it was: you > still can't just/solely replace the req-URI with the registered > contact URI, since that would lose the intended target info (the > specific user phone number which is being targeted). Ahah! I think we have here the tip of the iceberg on what's not being understood. Thank you for your question! To work fully transparently for contact-routing , a "wildcard" registration needs to provide a 1 to 1 mapping between AORs and Contacts. It isn't enough to specify a wildcarding for the AORs -- there has to be an homomorphic wildcarding for the contacts as well. If we use regular expressions to indicate the AORs being registered, we need to apply a matching regex expansion on the contacts being registered to the AORs. Here's one possible approach, using a non-regex model of expressing ranges (I believe Adam has proposed a regex model for the same thing). Assume we're registering "tel:+1972519XXXX". It's not adequate to register a contact of "pbx@pbx.example.org". We need to register a full set of contacts so that there is a one-to-one mapping from AOR to contact. So the "contact" being registered looks something like "sip:1972519XXXX@pbx.org ". If a call arrives at SSP for "tel:+19725199190" or "sip:+19725199190@ssp.com;user=phone ", the SSP can contact-route the request to "sip:19725199190@pbx.org". The PBX then has a fully-qualified URI to route the call to the correct extension. Of course, PBX could just has easily have registered using its IP address instead of a DNS name, and everything still works; contacts might look like "sip:197519XXXX@10.1.2.3". > > >>> f) One of the concerns raised so far has been on GRUU's. Unless we >>> figure out how to convert GRUU's to telephone numbers, there's going >>> to be a need to route a request for a non-TEL-URI to the PBX and >>> keep it a non-TEL-URI. >> >> >> GRUUs don't convert to telephone numbers. They map SIP Contact URIs >> (in whatever domain they exist) to SIP URIs in the domain of the GRUU >> minter. This is a pretty straightforward mapping, and the issues of >> "domain ownership" around it have already been solved. >> Yes, we need more work on minting GRUUs for "wildcard" registrations, >> but that's a rather more tractable problem, although AFAIK untouched >> by any existing draft. > > Yes, that was my point: GRUU's don't map to telephone numbers. They don't have to! They only have to map to contacts. We just need a similar wildcard-registration mechanism to allow the SSP to mint a set of GRUUs congruent to the set of contacts being registered. If the PBX is in-itself a proxy registrar, it then has to set up its own mapping table for those GRUUs and make them available to the UAs registering to the UAs. These GRUUs are then used for all call-transfer activity, meaning we never have "domain authority" problems on the resulting calls and that whole problem space evaporates. So when the PBX registers a wildcarded range like "tel:1972519XXXX" it uses a range-matching wildcarded contact like "sip: 1972519XXXX@pbx.com" and gets back a range-matching wildcarded GRUU like "sip:qwertyXXXX@ssp.com;gr". And we need a Require and Proxy-Require modifier that proves that the nodes know what to do when they see the wildcard syntax being used. We may also need a new REGISTER error response code for mismatched AOR/ contact sets. -- Dean From HKaplan@acmepacket.com Sun Jan 31 17:29:10 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79903A69F6 for ; Sun, 31 Jan 2010 17:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 KSbSJ43pQQj9 for ; Sun, 31 Jan 2010 17:29:10 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CCB473A6889 for ; Sun, 31 Jan 2010 17:29:09 -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; Sun, 31 Jan 2010 20:29:39 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 31 Jan 2010 20:29:40 -0500 From: Hadriel Kaplan To: Dean Willis Date: Sun, 31 Jan 2010 20:29:37 -0500 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqixJLYAtAHBxO1QlyoC1Js2G1/qAAF7WPg Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 01:29:10 -0000 So if I understand what you're proposing, on the wire the routed request wo= uld look like draft-shaken or whatever except the real registered Contact-U= RI is not inserted as a Route header. And the description of the process t= aking place in the RP is that it is doing rfc3261-style AoR->Contact resolu= tion, instead of "retargeting" to the domain/ip of the PBX. Right? I'm fine with that. I still don't think it requires Registering a Tel-URI,= though. I.e., the To-URI of the REGISTER doesn't' need to be a Tel scheme= for that to work. -hadriel > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Sunday, January 31, 2010 5:27 PM > To: Hadriel Kaplan >=20 > To work fully transparently for contact-routing , a "wildcard" > registration needs to provide a 1 to 1 mapping between AORs and > Contacts. It isn't enough to specify a wildcarding for the AORs -- > there has to be an homomorphic wildcarding for the contacts as well. > If we use regular expressions to indicate the AORs being registered, > we need to apply a matching regex expansion on the contacts being > registered to the AORs. >=20 > Here's one possible approach, using a non-regex model of expressing > ranges (I believe Adam has proposed a regex model for the same thing). >=20 > Assume we're registering "tel:+1972519XXXX". It's not adequate to > register a contact of "pbx@pbx.example.org". We need to register a > full set of contacts so that there is a one-to-one mapping from AOR to > contact. So the "contact" being registered looks something like > "sip:1972519XXXX@pbx.org > ". >=20 > If a call arrives at SSP for "tel:+19725199190" or > "sip:+19725199190@ssp.com;user=3Dphone > ", the SSP can contact-route the request to "sip:19725199190@pbx.org". > The PBX then has a fully-qualified URI to route the call to the > correct extension. Of course, PBX could just has easily have > registered using its IP address instead of a DNS name, and everything > still works; contacts might look like "sip:197519XXXX@10.1.2.3". From christer.holmberg@ericsson.com Sun Jan 31 23:30:00 2010 Return-Path: X-Original-To: martini@core3.amsl.com Delivered-To: martini@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50ACB3A680B for ; Sun, 31 Jan 2010 23:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=0.209, 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 9uykdFd2LFKv for ; Sun, 31 Jan 2010 23:29:57 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5C3823A6359 for ; Sun, 31 Jan 2010 23:29:57 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-81-4b668314b37f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id DD.4F.23735.413866B4; Mon, 1 Feb 2010 08:30:28 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.22]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 1 Feb 2010 08:30:28 +0100 From: Christer Holmberg To: Dean Willis , Hadriel Kaplan Date: Mon, 1 Feb 2010 08:30:26 +0100 Thread-Topic: [martini] Proposed work split: tackle telephone-numberregistration first Thread-Index: AcqixJS3noU8pYNTSUidIpb/PQCAGAARatoA Message-ID: References: <2118E1E7-735B-4829-B114-D524E5561E0F@softarmor.com> <130895FDE1B4488C82158D051A1D94D9@china.huawei.com> <6521ADA1-793B-4B43-A792-1DEBE5D68BD6@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 07:30:00 -0000 Hi,=20 >Ahah! I think we have here the tip of the iceberg on what's=20 >not being understood. Thank you for your question! >=20 >To work fully transparently for contact-routing , a "wildcard" =20 >registration needs to provide a 1 to 1 mapping between AORs=20 >and Contacts. It isn't enough to specify a wildcarding for=20 >the AORs -- there has to be an homomorphic wildcarding for=20 >the contacts as well. =20 >If we use regular expressions to indicate the AORs being=20 >registered, we need to apply a matching regex expansion on=20 >the contacts being registered to the AORs. >=20 >Here's one possible approach, using a non-regex model of=20 >expressing ranges (I believe Adam has proposed a regex model=20 >for the same thing). >=20 >Assume we're registering "tel:+1972519XXXX". It's not=20 >adequate to register a contact of "pbx@pbx.example.org". We=20 >need to register a full set of contacts so that there is a=20 >one-to-one mapping from AOR to contact. So the "contact"=20 >being registered looks something like "sip:1972519XXXX@pbx.org ". >=20 >If a call arrives at SSP for "tel:+19725199190" or=20 >"sip:+19725199190@ssp.com;user=3Dphone >", the SSP can contact-route the request to=20 >"sip:19725199190@pbx.org". =20 >The PBX then has a fully-qualified URI to route the call to=20 >the correct extension. Of course, PBX could just has easily=20 >have registered using its IP address instead of a DNS name,=20 >and everything still works; contacts might look like=20 >"sip:197519XXXX@10.1.2.3". I think that is wrong usage of the Contact header. You more or less use it = for carrying target information. We have other mechanisms for that. I also think it is a very "clumsy" solution, when you mandate a 1-to-1 mapp= ing of the R-URI/Contact userpart values (maybe it could also have security= impacts). Last, my understanding is still that, from a SIP network point of view, the= PBX is seen as a single Contact, but in your solution every PBX user expli= citly (eventhough a wildcard mechanism is used) registers with the SIP netw= ork. Regards, Christer
Topic: MARTINI WG Virtual Meeting =
Date:=20 Tuesday, January 26, 2010
Time: 9:00 am, Pacific Standard Time (San=20 Francisco, GMT-08:00)
Meeting Number: 969 608 430
Meeting = Password:=20 martini

------------------------------------------------------- =
To=20 start the online meeting=20
-------------------------------------------------------
1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D131322857<= /FONT>
2. Log in to your account.
3. Click = "Start Now".=20
4. Follow the instructions that appear on your screen.=20

------------------------------------------------------- =
Audio=20 conference information=20
-------------------------------------------------------
To = receive a=20 call back, provide your phone number when you join the meeting, or call = the=20 number below and enter the access code.
Call-in toll number = (US/Canada):=20 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serv= iceType=3DMC&ED=3D131322857&tollFree=3D0

Access code:969 608 430=20

-------------------------------------------------------
For=20 assistance
------------------------------------------------------- =
1. Go=20 to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support". =
To add this=20 meeting to your calendar program (for example Microsoft Outlook), click = this=20 link:
https://workgreen.webex.com/workgreen/j.php?ED=3D131322857&= amp;UID=3D483233937&ICS=3DMS&LD=3D1&RD=3D2&ST=3D1&SHA= 2=3DOq5aMj5r9wtLK2O-DYCma1jCyRz2sv5I/MMmlsQr8fE=3D

To check whether you have the = appropriate players=20 installed for UCF (Universal Communications Format) rich media files, go = to=20 https://workgreen.webex.com/workgreen/systemdiagnosis.php

http://www.webex.com=20